Learnings

A few months ago I posted a list on twitter about 10 things I have learnt in my career; things that I wish I’d have known at the start of my career.

In the next few posts I will expand on these points.

1) Short term fixes will 90% of the time become long term production processes.

Much as we like to believe that a quick fix will be just that; that we will come back to it when we have time and fix it properly, it is rare we will ever find the time to do so.

This isn’t about intentions or anything else. It simply comes down to two facts:

• This problem isn't an irritating enough 'itch' any more and so you aren't compelled to scratch it.
• Once it is in production it becomes business critical and it becomes far harder to do anything to change it.

This ends up being an excellent argument to fix it right the first time. Alas, in this business driven environment it is hard to commit the resources to doing it right when ‘good enough’ will fit the business need.

2) You will never have full requirements, if you do they are out of date.

TL;DR version: Agile and similar iterative processes are the right way to do things. Business and technology changes too quickly.

When I learnt about Computer Science in the early 90s there was no agile. Waterfall was the normal method taught and people used it - and projects failed.

Not all projects; that would just be silly and not a total failure. Just enough failure to mean that projects didn’t fit the changing business needs particularly well.

With the advent of drag and drop UI builders and languages like VB (much that I hate the language) apps were quicker to develop and fairly consistant in their UI.

Extreme programming and agile was an extension to this. They didn’t have all the answers but they changed the model from upfront design to incremental improvement. You could put a mostly working app in front of a user in a few hours and the user could start to understand what you were describing.

This accelerated the pace of the IT industry. We now see an MVP as an integral part of most startup’s business plan and the only people left doing waterfall or similar development methods are mission critical application developers (flight systems for aircraft and spacecraft, process controllers etc.) and government contractors who are lagging behind the times by about 20 years - although it is nice to see this is changing.

2a) Design with change in mind

This wasn’t in the original set, but I think it is important.

If you design and build tightly coupled systems then sure, you will get maximum performance out of the system. The problem is that changes to the system become difficult; changes to part of the system end up requiring changes elsewhere as the interfaces and data structures change.

With this in mind I tend to recommend loose-coupling using well defined interfaces now. Using interfaces like REST or Message Buses and interchange formats such as JSON (and XML if you really must) you can avoid the need to make changes in multiple places as business requirements change.