At the time of writing, I am about to change jobs after over 10 years in my current role. This, I suspect, is quite strange for the IT business. Given this, here are some thoughts on my experience of writing software and then having to be responsible for it for a long, long time.
Pay attention to errors
Paying attention to errors most definitely paid dividends over the years. My experience is that people rarely come round to tell you that your component is working flawlessly, they are much more likely to come round when something has gone wrong.
By paying attention to errors, I am talking about both throwing meaningful errors and handling them effectively too.
For me, a meaningful error is one that has a well-worded message and contains as much key information as is feasible at the point it is raised. For example, ‘Unexpected input’ or ‘Error 4235’ are not what I would consider well-worded. If viewed in isolation, which errors often can be, they are meaningless.
The mindset I would suggest is to put yourself in a position where all you have to work with is the message. Another tip here is to always have static text at the start of the message, to make it easier to locate in a codebase.
BYOM – Bring Your Own Model
Workflows in Workflow Foundation were defined by a XAML file, so the task could be solved by building a UI that walked the nodes in the Visio diagram object model and outputted the appropriate XAML for the runtime.
- To isolate the editor from runtime. I didn’t want the Windows Form editor to have references to the Workflow Foundation components. With an intermediate model this could be avoided.
- Workflow Foundation XAML V1 was a pure hierarchical model, so required some complex generation to model non-hierarchical processes.
- Workflow Foundation XAML was V1 and so was a prime candidate to change (and it did!)
KISS – Keep It Simple Stupid
For one project, we had to build a backend service that received files and queued them up to be spooled to the printer. I was under pressure from a senior member of staff to use a relational database as an index for the jobs.
In the end, I went with the simplest solution I could think of and made it all file-based. The result, simple to deploy and maintain. Need to retry a job? Drag it from the failure folder to the input folder. Need to test the printing?
Drop a file into the input folder. Simplicity really does help in the long run, especially if you have to support it.
This goes for algorithms, regular expressions, and data structures too. If you are going to be coming back to the software you haven’t seen for 5 years, you want to make it easy for yourself (not to mention others).
Attention to clean code really does make a difference
No surprises here, but thoughtful naming, reasonable method size, and all the other factors that result in clean code make a huge difference in the long run.
I was always happy to return to my own code, not because it was cleverer than anyone else’s, but because I always paid attention to those principles as best I could.
I tried to never let my standards drop and I was always very grateful for that on my return. Code is read many, many more times than it is written. Especially over the course of 10 years.
Log, log, and log some more
One lesson from supporting the same software for over a decade is that quality logging will be your friend. In my time, I inherited more than one area of tooling where logging was almost non-existent.
The consequences of which were that delivery using that tooling was difficult and error-prone. When redeveloping these areas, I made a point of ensuring that the tools explained what they were doing at varying levels of detail.
By using logging frameworks, these levels could be switched on or off. For production, there would be minimal logging for reasons of speed.
The key was to treat the logging as an integral part of the overall product and not as an afterthought.
Big Thanks to @Andy Blackledge