I do computer programming for work (php and python nowadays). It sometimes frustrates me, and I’m sure my employers too, how long seemingly simple jobs take.
Eg want to change a website’s font size? Seems like it should just take changing one setting somewhere from 10 to 11, right? Yeah that’s it… but don’t forget to factor in that now areas of text take up a tenth more space and so now all the spacing everywhere next to text (so probably everywhere) needs to be adjusted, now some words are too big for mobile devices and so need to be fixed somehow, and there will probably be a dozen other small tweaks that need to be made or something will look strange. And that’s assuming I only need to edit one line of code to change the text size. In reality I’d probably need to change it in a dozen spots too. And let’s also not forget testing it on a variety of browsers, screen sizes, documenting the change, and, if I’m collaborating with a team, discussing the merits of the change, best practices, and different solutions.
So although it originally sounded like a trivial 5 minute change, turned out to be a 2 day change. Oups.
So sometimes my work is painfully slow.
So when I embark on doing some task, I want folks to realize that I will probably be working at it for quite some time. Even if the task only took a minute to conceive, it may take hours or days to execute.
And although they may be paying me for the hours regardless of how good the idea was, job satisfaction has little to do with the income and a lot to do with feeling like you’re making a difference. (If they told me they’d pay me double to dig holes and fill them in again, I’d probably still prefer to do what I’m doing now.)
Does “change the website font size from 10 to 11” constitute a plan? It’s a command, not a plan. Nowhere in that statement does it show that the impact of this change has been considered. It doesn’t mention what the goal is, or how we will know if the change was successful or not. It doesn’t mention why that goal is even worth the effort. It doesn’t mention any prior experience you’ve had that led you to this “plan”. It doesn’t mention what alternative plans exist, which might equally meet the task’s objective in an easier way. It also doesn’t mention “prior art” (what others have done in similar situations).
So basically, it’s an idea that popped into your head with no specific goal, based on unknown experience (if any), that you haven’t considered what the impact would be, that may have a better alternative, that attempts to fix an unknown problem, which might not need fixing in the first place.
Well given that’s the situation, don’t be surprised if I’m not excited about doing it.
Continuing with the font size change example:
- what is the problem this hopes to fix? Let’s say it’s that some users are having trouble clicking the menu links from their phones. But otherwise, every one can read the text just fine.
- What is the goal? Allow them to easily click menu items from their phone; but also continue to have the website usable from a desktop computer, and continue to have site layout be basically preserved
- How will we measure success? Most likely, the elderly person who was complaining they can’t press menu links from their phone should be satisfied; and the site should continue to look good for users from s variety of age groups and technical skills, and a wide variety of browsers.
- How important is this? It’s a bit annoying, but there are other jobs which are much more critical to the business. So if it can be done in under 3 hours, great; any longer and we’ll just leave it for now.
- What possible solutions exist? 1. Increase font size throughout the entire site. 2. Only increase font size in the menu. 3. Increase the spacing between menu items, and leave the font size the same. 4. On mobile, use a completely different menu layout, which has bigger links ; but keep the menu the same for larger devices
- What will the impact be? For solution 1 it will affect the layout of the entire site, cause some words overflow their sections on small devices, and possibly make the text less readable; but hopefully it will make the menu items more clickable (but probably not very well because size 11 text is almost as hard to click as size 10 when they’re stacked next to each other anyway). For 2 just the menu might might have words which are now too big for their section, and areas next to the menu might l have layout issues, but everywhere else will be fine. For solution 3 there should be no words taking up more space because the text size is the same, but layout next to the menu might still be affected. And for solution 4 we will need to have co situ okay logic that determines the screen size, and design an entirely new menu layout and layouts for areas near the menu on mobile, but for desktop computers layout will be unaffected
- What prior art is there? The most common solution nowadays is the “hamburger menu” for small screen sizes, and regular menu for bigger ones.
- What experiences do I have that may influence my decision? For me, I don’t have a problem with zooming in my mobile device in order to click a button. It’s nice if I don’t need to, but I can live with it. But I know my parents would struggle with it. And the hamburger menu would probably confuse my parents, but everybody else I know is fine with it.
Ok so having considered all this, is increasing the font rise for the entire site the best thing to do? It seems to not be to me. It affects the most of the site and so causes the most work (certainly more than 3 hours), and I don’t think size 11 menu items will be much easier to click than size 10. So the original dominion doesn’t look like a good fit.
Now what about solution 2? It’s less work, but probably won’t fix the problem much better.
Solution 3 is certainly the easiest and is likely to fix the original problem. But it won’t be as smooth as solution 4. And it will make theme bu look a bit worse on big devices where the extra space isn’t needed.
Solution 4 will work great all around, but it might be more than 3 hours work to tell develop and test this more complicated work. Also it means we will have to always support two kinds of layouts. Also, having a hamburger menu might not be intuitive for older folks, but this site’s traffic is from a variety of age groups, so that’s not a huge issue.
So given the data considered, I think solution 3 is the best fit: it will solve the problem in the alloyed time, whereas option 4, although probably better and more common, seems difficult to execute in the given time frame. But seeing how you’ve given established the goal and timeframe, maybe once I step into the code, I see that solution 4 is feasible in the time frame too; so I can make that decision given the new information.
But you think “who has time to do all that planning for some tiny task like that?” I have several items to mention:
- I agree that it’s unreasonable to spend an hour planning a task that will only take 10 minutes to complete. However, I think taking 2 hours to plan a task that will take 10 hours to complete us much more reasonable. I think let’s keep the proportions similar here: I think a ten hour task merits about an hour of planning.
- If you don’t have time to do all that planning, please assign someone to do it. Give them some direction, like your objective, how success will be measured, and a ballpark office much time and resources to put towards them. Share whatever information you already have, like what the problem is, a bit if your previous relevant experience, knowledge of prior art, what possible plans you already know about, and some guidance about where to look for assistance, and when to get feedback from you. Then let them take care of planning while you do whatever you think is more important. And yes I can do the planning of you need, but I need to know what the problem is, what your objective is, and a ballpark of how important this issue is. So just a few sentences, but certainly not just a command.
- From my example, notice although the extra planning took a bit of time, it saved us from attempting the initial solution, which would have actually saved time. And because it defined the objective of the change, we can know right away if it’s working; and because we defined how important the task is, we can know when we’re over budget.
In the programming world, two main ideas of how to develop software exist: the waterfall development method, and agile development. Waterfall dictates that you first plan out absolutely everything, then develop exactly that, with no variance. Whereas agile is more iterative: you plan a tiny bit, develop a tiny bit, and try it out; after you’ve tried it out, you’ve learned that you’re original plan was probably wrong and so you start again. The idea being that your first plan won’t be very good, no matter how long you take, because you learn the most during development and testing, so get to those steps as quickly as you can.
So am I advocating the waterfall development method? Not exactly. I think I’m just advocating not skipping the short planning part of agile. If you haven’t established what the goal is and how you will evaluate success, when you develop and test it, how do you know if it’s any good? And if the task was into ally done with no way to judge its success, don’t be surprised that later on, when you introduce a way to measure success, that it’s not “successful”.
Well this is all my opinion, not backed up by references or studies, so I could be completely wrong. But worth chewing on anyway.
Even if you have considered, still good for me to know and see it. I can see opportunities while coding, and I will feel more accomplished.