"To test or not to test" : a startup dillema

Despite being well-established in enterprise software development, usage of the tests in dynamic startup-like environments can still be questionable. Having different angle on the software purpose itself - often characterized by "just write something fast, so that we could demo it, and then throw it away"- sort of request, the engineering management is forced to carefully reconsider the trade-offs of (not) introducing a tests into the development process.

Being essentially a gambling turf, in which companies bet on success or failure, startup world is a place in which the best thing one could do is try to do all he can in order to turn odds in his favor, and then hope for good wind in the sails. Adding tests as a part of the process in such environments, at first, doesn't seem like it would do any good in biasing the dice for us, so it's often totally neglected, especially at the beginning of the process. Also, startup teams usually consists of relatively small number of developers, working on a piece of the code, which by definition, requires a significant multiple of that number to be properly done, and allocating some of these scarce resources to something "useless", could really seem like a luxury one cannot afford.

Additionally, in more open minded environments, there is a significant obstacle to introducing tests in small agile teams, and that is the issue of having to keep the team constantly focused on the goal, rather on the details. Namely, being extremely goal-driven, and horribly time-limited, the only way for getting the project done is by rapidly progressing towards the goal and consciously neglecting issues that keep popping up along the way. Having tests in such environment (particularly unit tests) - one is forced to constantly notice those issues and can over time completely loose the focus, which might lead to project failure.

However, though the tests won't get the product done faster and excessive focus on tests could lead to it's demise, there is another side to the flipping dice, that can result in the product failure even though all the features of it have been done properly and on time. For example, the customer might simply change it mind, the market could change at the exact moment the product is out, etc. That is the moment when the investment in tests will pay off. Namely, having software developed with unit testing in mind, automatically forces software to be designed as "testable", and usually, more general and reusable. Such software could easily adapt to the new situation, that might require partial rewrite of the system - in which case ill-designed system would require full redo, and would often yield retract from any further work, and simply admitting project failure. Well-designed system could, on the other hand, keep fighting, reuse it's stable base and move on, which might be a characteristic crucial to the startup's eventual success.

Therefore, one should try and start with the "middle road", as far as the tests are concerned - that is, get them into the system, and have them shaping the development process, but keep them at the minimum level that won't jeopardize other aspects of it. As the time goes by and project advances, the "test volume" should be dynamically tuned up and down, depending on the progress. Tuning that knob properly along the timeline, could shape a curve that just might be the one separating the successful projects from the failed ones.

On Softwareoids

A subdivision of a project into many single-person teams, can often lead to a weird phenomena that can be characterized best as a "human-based software". This is somewhat weird beast, that is usually spawned by assigning a huge project to a single individual. Necessary ingredients to this is (a) having a developer willing to commit to work for more than standard 8h-timeframe ; (b) having a developer lacking a social life (or willingly neglecting it for the sake of work, which he bizzarely considers more "fun").
Facing such person with huge and responsible task, produces the following reaction to given criterias of a task :

a) "It's huge" => "great, i like challenges, and this job is about fun, right ?"
b) "Responsible" => "no problem, if i don't manage to do it properly i can allways stick around the system at all the time (I don't have a life, remember :) ).... and be there to handle it manually if it mailfunctions

Now, reasoning in b), although seemingly courageous, can get everyone in tremendous trouble, not just because of the "golden boy" situation it generates - once that is in production fast, there is no time for it to be rewritten properly, and the person accepting b) becomes your most valuable asset (more than the software).

The main antipattern here is that from software engineering perspective - this had created a hideous beast - a two-headed monster, we might call a "softwareoid" - a code incapable of existence without its maker.

Once in the wild .... that creature can create horrible things......

and that is what this story is all about .....

(to be continued)