The Case for Slow Programming

I feel like "agile" has come to mean "get shit done fast" in today's programmer culture. But just as "agility" and "speed" are not the same, agile development does not necessitate a race to the finish and similarly is not the antithesis of the slow programming style (as some commenters seem to be suggesting).

I think people have wrongly used agile as an excuse to implement first, reflect later, refactor never. In the original agile movement, there is a lot of time devoted to refactoring. You hack something together that accomplishes your goal. You get to see how it's working, get user testing up and running, and then reflect. But underneath the hood the program is a complete mess. This is the time for an agile developer to go back and majorly refactor the program into a neat, well-organized system. Maybe even rewrite. The problem is people on the business side of things see a near-complete project that they want to launch ASAP. It may even feel that way to the developers. I think the refactor part of the process gets cut short because of the desire to push the product out the door or work on new feature sets. You're only doing half the agile process in this case.

I'm definitely not in the "plan first, build later" vein of thought. It's not how I program or do artwork (I'm a hobby artist as well). I need time to play around and experiment with different ideas in real-life implementations before settling on my plan of attack. There are so many ideas that may seem great in your head, but don't do well IRL. Additionally, you may stumble upon a new idea in the process of experimenting.

The thing I long for the most as a programmer is more time to refactor. Time to refine my code. There is something to be said about craftsmanship as opposed to mere production. One thing I've enjoyed about my own personal programming projects outside of work is that I have time to sit back and reflect. Is this the best way of modeling X? Is there a more simple way of expressing X? And then I can do major refactors/rewrites that would never fit into a sprint at my workplace. But I do believe the investment will pay off in the future when it comes to maintenance. And extra day refactoring now could save weeks of debugging later on.

Software Craftsmanship Vision See http://kp0.me/SoftCraft

The problem is that Software is in fact a new kind of object, i.e. it has a different ontology from most other objects which is defined by what is called Hyper Being by Merleau-Ponty and Differance by Derrida. This is in contradistinction to most objects which are either Pure Being (present-at-hand) or Process Being (ready-to-hand). Hyper Being objects are defined by Derrida in terms of differing and deferring, but we can talk about instead decoherence and delocalization of Software. Delocalization has to do with the fact that design elements are spread out within programs and in spite of object oriented design are not self-contained at the program level. Decoherence has to do with the fact that programs lack internal coherence intrinsically due to the nature of general purpose programming languages and their multi-paradigm nature and the solution to this is aspect oriented programming which attempts to render coherent elements that are non-localizable. But neither aspect oriented programming nor object oriented programming completely solve the problem of the intrinsic quantum like properties that occur in software. Software designs are like classical physics in relation to the quantum like nature of software. See my original paper on this called Software Ontology at http://kp0.me/SoftOntos. There are in fact various ontological levels identified in Continental Philosophy and beyond Hyper Being is Wild Being and Ultra Being which both have implications for our understanding of Software.

Also I don't see any reference to Fast and Slow Thinking by Daniel Kahneman. There is some basis for understanding the difference between Fast Thinking and Slow Thinking in his work. Fast Thinking makes up narratives on the fly while Slow Thinking creates arguments more ponderously. Actually in Software Craftsmanship we need both and we need to balance these two forces in the patterning of our development processes.

Kent Palmer http://kdp.me

Good point. How many "rockstar" developers show up at Company X, build the initial versions of a product or architecture, then move on to the next company never to understand the longer term consequences of their choices?

Indeed. I needed some paperwork when I got married with a german. I'm from Sweden. I called the tax office in sweden that was taking care of the papers I needed to file for marriage certificate in Germany and the woman on the phone was laughing heartily saying "Then you know how byrocrazy feels!" :-) They happily sent all papers I needed in the mail to me in Germany, translated to English. The clerk in Germany was eying it suspiciously and asking some colleagues and took quite some time before finally putting down his stamp.

I brought up NextSTEP because it was a notable success that was not mentioned by the parent comment.

And arguably, NextSTEP is a success story because of its design which enabled it to crossover successfully into mobile through iOS. NextSTEP's blueprint allowed iOS to operate at a performance level that other OS'es and architectures could not match when it debuted.

BeOS was fine, but it was rightly or wrongly seen as a spiritual successor to Amiga, which only had a niche market.

NextSTEP wanted to be a spiritual successor to MacOS, but never really could until Steve Jobs forced it in there.

Even so, the technical design points of NextSTEP were well-suited for a resource constrained mobile platform, and that is one reason iOS has been such a success.