This post was originally published on my Jump Start blog
“It's not the ink–it's the think,” wroteÂ Robert Mankoff (New YorkerÂ cartoon editor), answering to the question how to get ideas for cartoons by people who want to submit them toÂ The New Yorker. "There really is no trick–you just have to think of them" he said.
It's the same in creating a software.Â
Writing the actual code is only a small part of the process. Opening IDE to bang out a solution upfront is rarely the case. First, you have to understand the problem and break in into pieces. After some time you will start to see the patterns and solve the problems without too much thinking about them, but even then the more complicated tasks will require quite a think.
I like to write down the problem.
I draw it on a whiteboard or on a flipchart. It gives me space to think and write extra ideas or different approaches. I see the dependencies clearer this way. When working on the complicated task IÂ ask myself: What do I know about the system that it's about to be built? What should be built? What goes inside and what's the expected outcome? How it connects with the existing system.
In enterprise projects, you usually have user stories, requirements etc that help you answer those questions :)
Smaller features are easier to manage. Easier to test. Easier to write. So think in small batches. Complex applications are composed of smaller programs working together.
Think of the result from the start is one of the best software development practices. Developers do this usingÂ test-driven development, orÂ TDD (see more in Google).Â
Figuring outÂ whatÂ you want to write before you figure outÂ howÂ to write it seems an obvious first step. But many developers take a shortcut. They charge straight at the water and dive deep to get out of breath pretty soon.
Taking the time to design the program speeds things up in the further development. A poorly designed code is hard to maintain and extend.Â The untested, unplanned code in production, requires painful changes to it later.
And who likes to do the maintenanceÂ only?