Fail to plan and you plan to fail

Recently, I was tasked with one of those improvement requests from users. The web application in question was to be enhanced to cater for more complex user roles.

“How many man days do you need?”, my team leader asked. I gave a rough estimate and said I’d have to think about the solution.

Off the top of my head, I’d have to modify some database tables. That would affect the query statements in the business logic classes. Which might mean some code changes. Then there’s the problem of displaying the data according to the more complicated user roles. And I still had to ensure secure retrieval of data.

So I thought about it. I scribbled notes. Drew some diagrams. Thought about it some more. Took another piece of paper and plopped some fake data on it. Crossed out some of the fake data. Redrew the arrangement. Scrutinised existing database schema. Compared with arrangement on paper. (Now you know why my desk is a mess) I even thought about which code parts I needed to change.

During this thinking phase, I might be

  • Sitting still and staring at monitor
  • Sitting still and staring at piece of paper
  • Staring up at ceiling with feet tapping along to music beat on my earphones

At first glance, you might think I’m doing nothing. I’m not. My mind is whirring with activity, busy displacing images, reasoning through logic and considering alternatives. I find it faster to move diagrams and table structures around in my mind than to redraw them on paper. Ideas are committed to paper when details start overflowing.

After maybe 5 days of scribbling and thinking (while fulfilling my other work duties), I felt I was ready to start actually changing code. Luckily, I was the original (and only) author of the web application, so I was already familiar with the code.

Why did I take so long then? Because I had to plan for future expansion. I had to plan for possible new marketing ideas from users. I had to plan for the possibility of someone else taking over my code. Plan, plan, plan.

When I finally fired up the source code in Visual Studio, I only had to do find-and-replace operations, minor code changes, and refactoring property and web control names. And all of that was done within an hour. Then I only had to test that the web application worked as before, with the new business rules added in. Which took up another few days.

As a programmer, some of your project tasks will have very little to do with actual coding. The real value of good source code isn’t hammering the code out in record time, but the thought that goes into it.