Quite recently I've had an interesting discussion about the differences between developing applications in various IT ecosystems (OS + platform + language + IDE + libs + ...) - why do some of them suck (always suck / usually suck / sometimes suck) and why some suck more than other. Obviously, these questions are not easy to answer - or even not possible to answer in a fully comprehensive way, due to number of factors to be taken under consideration and due to the fact that some ecosystems are that different that comparing them just doesn't make sense.
But our discussion evolve towards one, very interesting (and usually poorly understood) aspect of IT ecosystem's quality - the development agility.
Agile? Are you going to go through Scrum again?
Nope, the word agile simply gets too popular nowadays - the development agility doesn't have much in common with agile software development or agile project management.
Development agility is the measure of how your tools limit (by being a non-necessary burden) your creative mind-power in crafting software.
Le what?!
Just focus, it's easy. Let's start with some examples:
If there are 2 teams developing 2 separate .NET applications using the same toolset & platform stack, but:
- each compilation of Team #1's app takes 30 seconds and compilation of Team #2's app takes 10-15 minutes ...
- Team #1 can test their software immediately and Team #2 has to wait until scheduled EoD processing ...
- Team #1 are able to test everything on their local machines & Team #2 have to exclusively allocate core-system time to perform their test in isolation ...
- If Team #1 breaks their DB data coherency they can exec their purge scripts & continue in a minute, but if Team #2 does the same, they need to send a formal request to a different team to have DB recovered in just 48 hours ...
... are both teams working in the same conditions? Are they able to deliver software with the same velocity?
Don't underestimate the costs of poor Developments Agility:
- It slows down coding - not only making the new functionality, but all the maintenance as well.
- It impedes automation, for instance: in testing. And lack of automation in testing causes longer deployment cycles (because manual testing is expensive).
- All of the above increase the software craftmanship costs.
The Feed Tractors, ... I mean Key Factors
What does Development Agility mainly depend on?
Pretty much everything - we can list a lot of both technical & non-technical factors:
- how independent teams are (in terms of not waiting for external "services")
- how formal are the procedures of work
- particular technologies used & their specifics
- the technical inertia (amounts of data, code, text)
- application(s) architecture
- how development process is set up (and how erroneous it is)
- the level of automation
- tooling (starting with IDEs, compilers, CI, but also validation, monitoring tools)
etc.
So, the bottleneck can appear anywhere and there's no one single, particular place to watch carefully, BUT:
Non-technical bottlenecks can be quite easily removed
People just have to identify such an impeding element and collaborately remove it. Obviously it may not be easy, but usually it's still much more feasible and just easier to re-engineer the process than to swap the core technology whole company is rooted in ...
The fan with the shit injector attached
The truth is that some technologies (usually the legacy ones) are just beyond any hope:
Hints:
- if your tooling is 80x25 terminal with a text editor (as an IDE) that looks like VIM's antediluvian primogenitor ...
- if your language of choice pretty much didn't change at all since 1985 ...
- if navigating through the codebase relies on grep-like commands and / or directory structuring conventions ...
- if all the utility libraries (all 3, I mean) and the platform itself is a outrageously expensive blackbox with documentation in early LaTeX ...
- if you live in environmental communism (all developers shit into shared environment without any kind of reasonable isolation) ...
- if you haven't heard about any new application, framework or library created in your tech since 1992 and all what remains are thorny weeds in maintenance mode ...
- if debugging is so painful that it's more efficient to re-write the code from scratch ...
... you may be lacking a bit in terms of development agility.
Or you can fool yourself that you're not and it doesn't matter because it all runs so smoothly since 1982 and no-one ever complained - or at least no complains went through the cobwebs you live behind ...
