Living dangerously

11 November 2013
Back when I was in New Zealand one description of companies I have worked in was to say that they lived dangerously. Although pejorative on the face of it, and the term deliberately invokes thoughts of extreme riskiness, I used it in a much more neutral sense of the matter-of-fact way some companies operate in the fast lane. This is actually surprisingly common, and quite often it is down to necessity rather than choice, but it also has its plus sides. The main feature of companies living dangerously is the almost complete absence of any formal procedures, with pretty much the entire software development process being delegated to the programmers. A major effect of this is the lack of any real specification and/or design phase, and as a result the whole software life-cycle becomes dominated by time spent writing code. A lot of the time the end result is that bit too dependent on the grey area between experience and luck.

Why?

To some extent it is down to companies not knowing better, but more often than not it is a consequence of having very small development teams. It is partly resistance to change, but Agile methods with their dedicated Scrum Masters are simply too expensive. Employees are very expensive, and some of these companies do not have much in terms of financial safety nets, so having people do anything other than write code is a big ask.

The upside..

The good side of the seemingly chaotic way of operating is the ability to have fast turnarounds, because very little gets in the way of the developers getting down to building whatever system needs to be created. For the developers at the coal-face, it allows them to call a lot of shots they would not be able to otherwise, perhaps in a few cases shots they ought not call, and this perk cannot be overstated. In good conditions this allows for quite complex bits of software to be implemented in very short periods, and this is because advanced software development in many ways is much nearer an art than something that can be hammered into the framework of a mechanical process. It also allows developers to go on tangents that would normally be very difficult to normally do on company time, and in my case some of these ended up being fed back into company business logic.

..and the downside

The major down-side with shying away from use of formal procedures is that the same mind-set usually leads to even low-hanging fruit going out the window, which in my books is source code control and bug tracking tools, which from personal experience these are two things that should not be skimped on. The reasons I have detailed previously, and the worst part is that a relatively small investment would have at least mitigated some of the worst SNAFU I have come across. The problem is one of mal-coordination, the end result being developer time being wasted doing things that should not even be a human process, and that effort usually lands on a single developer rather than being spread uniformly. In my case it was effort wasted trying to keep the whole code-base in a single place.

Where it really falls apart

Even with the lack of formal processes, some informal ones evolve that bring a decent measure of order to the whole process, so the notional disorganisation is not usually as bad as the business school lot let you believe. However there are still some very nasty breakdown cases, and it is usually some variant of poor requirement handling. While good software engineering should allow for flexibility, there is only so far some critical assumptions can be deferred, and there comes a point where decisions end up being taken speculatively. While this in itself is actually a good skill, it is also asking for trouble.

The typical end-game is a load of over-commitment because sales/management simply say "yes" to every single late request, and it is absolute pot luck whether these slot right in or need to be hammered into place. One way or another there is gambling in the process, and it is QA that ends up taking the hit. Whether or not it works out, it is a fast track for developer burnout.