Programming is the last thing you should do

By Andrew Clifford

When you are developing a system, programming might be one of the last tasks in the project plan.

I have just finished working on a project to develop the data integration and storage for a data warehousing initiative. We had a challenging deadline, and needed to organise the work very carefully to meet it.

We did meet our deadline and delivered on time. But two weeks before the end of the project, we were only just starting the bulk of the programming. I felt a bit unprofessional, as if we had left most of the important functionality until the last minute.

But when I thought about it later, I decided that we had approached the project in the right order. On the office wall, I keep a reminder to help me when developing our own web-based products. It reads:

This reminds me to take an incremental, outside-in approach to development. Look at outputs first, and check that they are usable by creating a working model. Document what you are going to do. Make sure you can verify it by creating tests. Lastly, do the programming.

I wrote the list to make me focus on the important parts (usability and verifiability) rather than just hacking code.

The project I have just completed was a very different sort of project, building back-end infrastructure rather than web-based applications. But in essence we followed the same approach.

Our first tasks involved creating examples and documentation of the types of database tables that would be the ultimate output of the work.

We spent time thinking how we could test the work. We created stored procedures and scripts to check that the data in the database is as we intend.

Our first development increments focussed on the hardest things such as the technical architecture, to make sure that the overall design fitted together. We did these first because they had the most technical risk, even though they involved less programming.

We wrote lots of tests before we started the bulk of the coding. We created a complete sample scenario to exercise every condition in the system, and built a complete set of regression tests around this.

Lastly, we tackled the final coding.

I think the order we took is right. Of course it would have been nice to have more time on polishing and exercising the code. But we were very pushed for time, and had to focus on delivering in the right order. Programming is not the hardest or riskiest part of a project. To de-risk this project, we needed to focus on the required outputs, the technical architecture, the overall design, and how to verify it, before we started hacking code. In many projects, programming is the last thing you should do.

Subscription