This post was originally published on my Jump Start blog
It's not the ink–it's the think
“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.Â
Turning Problems into Code
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.
Understanding the Problem
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 :)
Breaking complex programs into pieces
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.
Driving Design with Tests
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).Â
Writing the Code
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?
Oldest comments (0)