Editorials

Coding Fast or Slow

Are you coding? You can ask me this just about any time and my answer will be, “Yes”. Even though I enjoy employing agile techniques for software development, it doesn’t mean that I don’t have a strategy to solve a problem. It doesn’t me there isn’t an architectural process, or no cogitation, about how to solve different issues. It just means, I don’t have to have a completed set of diagrams to prove an implementation before coding begins. I replace those diagrams with working code and unit tests. But, the same amount of thought and effort go into the design as if I were starting out with a Class Diagram.

Back to the main point. Using agile techniques does not replace the need to design a solution. Frequently I come across use cases that are difficult to implement, processes where there is no simple flowchart, and the number of conditions grows to where it is difficult to keep it all straight.

Many is the time when I will be doing something completely different from writing software when the solution for a difficult requirement presents itself in my thoughts. I guess that my subconscious is ruminating on the problem, even though I am not directly focusing on it.

Some folk consider Agile to simply be fast programming. I would counter that the primary thing that describes Agile is using code to do as much as possible when writing software. If you can build an architectural design using code instead of UML, the using code you have something that works, not something that looks pretty and can be handed off to someone else to code. There is nothing about how fast you code of which I am aware.

Don’t get me wrong. I have no problem proving out a solution by writing a software prototype really quick. I’m willing to throw it away or refactor it if that takes less time. The intention is to try something and expose what you don’t know.

At the same time I find it helps to not feel like you have to be writing code 100% of the time. Sometimes it helps to take a step back and put together a roadmap for how the different aspects are going to work together; especially when you are collaborating with others.

In short, the tempo at which you code is not the issue. The issue is are you taking an appropriate amount of time to direct your coding effort to get the most value.

Is this vague? Perhaps you can help clarify with your own thoughts or experience. Leave a comment here, or drop an email to btaylor@sswug.org.

Cheers,

Ben