Everything You Know is BackwardsWhy does writing software take soooo long? And why is it always the easy things that seem to take forever? Have you ever had the experience of coding up an incredibly difficult looking algorithm? It can often be done in a few days or even hours once you understand how it works. On the other hand, something as simple as putting together a small web site that looks nice can take weeks or months. There are a few things going on here. The first is confusing time and competence when solving a problem. Just because a problem is extremely difficult, doesn't mean it's going to take a lot of time. If you know exactly what to do, it may be possible to do it very quickly. And if you lack the competence to do it, then it simply won't get done. On the other hand, an easy problem isn't necessarily going to get done faster by someone more competent. Unfortunately, when you first begin a task that appears easy, it's all too tempting to allocate a short amount of time to it because of the level of difficulty instead of considering how much work is necessary. Returning to the complex algorithm example - there is more here than just easy and difficult. Consider for this particular task what needs to be done. You're trying to get this algorithm to work and maybe tweak and modify it. Although it may be extremely difficult to implement and understand, you only need to do one thing and you know exactly what that thing is. There is an input and an output. Once you get the output to look like what you expect, that's it. You're done. Consider the web site example. It's completely open ended. Can you even define exactly what the goal is? How do you know when you're done? The first task is difficult to comprehend and implement but easy to complete. The latter task is easy to comprehend but difficult to finish. The few programming type jobs I've had so far weren't overly mentally taxing. But it seems things just take forever. And I believe it has to do with maintenance and perfection. Writing software that nearly works most of the time is easy. Maintaing the code, changing or adding features to satisfy new requirements is a pain - a royal pain. It requires going back and looking at code you haven't thought about in a while. And it seems like there is always one more little thing you have been neglecting that needs to get finished. Even more frustrating is the perfection aspect. It can't be close to working. If it's going to be sold, it has to at least appear near perfect in the eyes of the customer. And it's always that last little bit that you can just never seem to get. Maybe it's because the technology to solve the problem just isn't quite right or because no one is sure what the GUI should look like or because there's that one obscure bug that only occurs on Monday after lunch (and keeps coming back after it's been fixed). It's the old 90-10 rule. That last bit is going to suck up all the time whether the task itself is easy or hard. And last consider the issue of how well understood the problem is. Do you remember that one class in college where the professor didn't understand the material either? I bet that was fun, wasn't it? When implementing a complex piece of code with a known problem and solution, it's often the case that a large number of very intelligent people have worked on it. Thus there's lots of good information describing what you need to do. On the other hand, with the day to day coding you do, it isn't as clear what code is good or bad or how to go about completing the task. There are lots of ideas and some of them work, but it's messier than looking at a very specific problem that many brains have studied. |