Inking and thinking in software development

No comments

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 implemented? 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. 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?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s