Software creationalism is a flavor of software development that is inordinately, irresponsibly, and often destructively concerned with the initial creation of an application’s code.
Tool vendors – especially in the Microsoft space – target software developers with a barrage of presentations on the wonders of wizards, drag and drop data-binding, smart tags, application generators, etc. These kinds of things are aimed at going from having no code, to having as much code as possible, and to do so with very little micro-iterative practice in play.
Software creationalism is almost entirely a tool vendor’s game – and it’s not a game whose intension is to benefit tool users. Software creationalism is about bloated IDE’s and code generators. It’s about how to distract users from critical issues in software development and keep them mesmerized with the smoke-and-mirror veneer of software creation tools.
The vast majority of the costs associated with a software project are in maintenance. Why all the focus on the creation phase?
It’s much easier to sell software creation tools than software maintenance tools. After all, you’d first have to undo years of perception bending of Microsoft customers toward the irrational and unfathomable fixation on software creation. And with so much predilection built up over the past ten years toward whiz-bangy software creation flashing lights, sparkly things, and bells and whistles, you’d almost certainly have to make software maintenance tools that pander to this visual sensationalism. Interestingly, a tool like Developer Express Refactor seems to have been doing good things in this context (although JetBrains ReSharper still has my vote in regards to raw practical power in line with agile development practices).
It’s desperately sad that software maintenance tooling and practice gets so little attention from the unwashed masses since it’s this area of focus where the greatest benefit can be had and the greatest progress toward sustainable software development success is made.
In this light, it’s hard to not cast Microsoft as an ethically incorrigible super villain in the world of software development. Microsoft has to keep its customers distracted from the real issues in software development since it doesn’t offer its customers practical options for developer tooling for software maintenance that aren’t overshadowed by its software creation tools. Furthermore, Microsoft’s developer guidance and even its architecture guidance is almost exclusively focused on keeping customer attention on software creation.
Microsoft doesn’t hold all the blame. The best we can do is to say that Microsoft is ethically-challenged. There’s no news there. Customers participate in this cycle as well. It’s through their own ignorance that they allow themselves to be taken to the cleaners. But, it’s an ignorance that is cultivated by Microsoft – which is ultimately very hard to turn a blind eye to. It’s a sickening kind of predation to bear witness to.
To be focused on software maintenance means to focus on those core concerns that ultimately gave rise to the agile software development practices. Software has to be changeable, and thus tested, and thus testable, and thus designed for testability. It should be built using inspective and adaptive processes. Its code must be literate and learnable to the extreme. The tools, languages, and frameworks used must be crafted with an understanding of micro-iterative development practices.
The tooling for software maintenance is mostly free and open source. The practices that support maintenance and sustainability can’t be communicated in the time that a mere tool can be learned. This is evidenced in the adoption of NUnit in absence of comparable adoption of Test-Driven Development; especially when the makers of NUnit have affirmed that the product roadmap for NUnit prefers features that benefit TDD versus features that benefit mere testing. Problematically, the subtler levels of practice where a number of the agile practices live are hard to even perceive until you’ve lived and worked there for a while.
The pay-offs for forcing your eyes from the seductive glow of software creationistic sensations is tremendous. The weaknesses in sustainability resulting from creationistic tools and practices are often either dramatically reduced, or eliminated altogether.
Software is only new for a very brief moment in time. Once a line of code has been committed to the screen it’s already in maintenance mode. You will spend vastly more time on average in changing that new line of code than you ever will have spent on creating it. To focus all of our efforts on mere software creation is to engage in negligence bordering on malpractice. To foster and encourage this kind of creationalistic thinking for one’s own benefit is simply unacceptable.
Software creationalism is all about short-term thinking. As long as you don’t expect your software to live longer than the time it takes to initially code it, creationalistic approaches will more than likely suffice. The real game in software is in maintenance and sustainability. We need to be looking to platforms, languages, tools, and frameworks that foster our ability to engage in sustainable development. Otherwise, we’re merely bringing the dog and pony show back to the office and trying to build an improbable future on it.