Some thoughts on development with a bit of a focus on devops type development. This all seems superfluous, but if I got a dollar for every time it was either completely discarded or done incorrectly I would be be eating a steak dinner tonight.
My first software job ever was to bring a mission critical application back in management. Me and a few co-workers spent close to a year digging through undocumented code and tools without clear purpose, setting up build scripts and writing documentation. You learn really well how expensive badly written, badly maintained code is.
The main aim is to reduce the amount of “Oh shit” moments. And whilst taking your time to do it correctly may not be needed or sexy at the time, having to respond to incidents by half-assed work or having to re-do a project is even less appealing.
The other extreme is to over-engineer everything, which is also not ideal. The term “engineering delight” is not uncommon in an environment where the some people have the term “obsessive compulsive” in their bio.
The happy medium is to do right by future you or the underpaid intern that has to look at you stuff and make changes.
Development cycle #
A normal development cycle sort of looks like this.
Incentive #
Incentive is the reason for doing the work. It could be an incident, a new requirement or a desire for existing improvement.
Isolating the incentive (the “why”) is important to ensure that the design and development are actually aimed towards what is needed and not just what is deemed right. You can also use this to communicate to the requestor and make sure you are in the same page.
The incentive is also the way by which you verify that the work is actually complete as requests.
Isolating the requirements from the solution also ensures you can compensate for changes in solutions if there are any. An example of this would be the ever present migration to (or from) cloud. The requirement is the starting point, not the tools, services or procedures.
Also make sure you have a way to register the requirements, designs and what not. It can be a simple document, a wiki or specialized tool. The important (to me) is you can trace each action to a requirement
Design #
Note
This part is not always required, but also too often skipped.
The design phase is where you sit down, and think about how task is going to be done. This is where you can think about the architecture, the tools, the
These can then be registered in a tool, document, wiki or even the ticket (if you received one and don’t care about actually finding it again).
Development #
In an ideal world you only work on the one task at a time, but in reality you have several. This means that for every environment you will need a reliable way to