You can find countless blog posts by software people claiming that writing code is a craft, science, or art. You can find an equivalent number of posts stating it is not a craft, science, nor art. Some like to split hairs and claim our titles define us: coder vs programmer vs engineer vs developer. The earth shattering insight to be gained from all this is that writing software encompasses a large variety of tasks, and that programming means different things to different people. This results in the adoption of a variety of methods trying to perfect the process of software creation. Unfortunately, restricting how programmers work in this regard requires a trade off that in many cases is counterproductive.

The collective body of knowledge used at any given time to support “best practices” is a moving target. I remember years ago (get off my lawn damn kids) when I was lambasted for not using a third-party template system in an Open Source web application written in PHP. Two years later I was reading about how using a third-party template system added unneeded overhead and projects that used them were poorly designed. I’m not saying this just to point out that I am consistently two years ahead of the curve, though that anecdote is a nice proof so feel free to be impressed. Today’s best practices can quickly become tomorrows regrets. A healthy dose of common sense goes a lot further than a Hacker News consensus when it comes to making sound decisions.

Since writing software is perceived dramatically differently by those that perform it, the enforcement of a strict development methodology restricts creativity in a way that limits a developer’s performance. All successful organizations impose some level of structure on their workflow. I’m not suggesting development shops devolve into a code slinging free for all, but I do think there are gains to be had if we lighten up on fierce adherence to unyielding paradigms. Software development is for me a very creative process. Trying to box that creativity  into a one size fits all methodology inevitably diminishes its expressiveness.

There is no silver bullet for creating bug free software. If there was we would all be kicking back with our feet up on the desk shooting shiny projectiles wildly around the room while untrained monkeys generate flawless code. The most important assets to producing good software are the people behind the product. No automated test system can replace a programmer with a deep understanding of the problem domain. No development methodology can compensate for a coder that does not have an adequate skill set. Give developers the freedom to choose their editor and IDE, and their approach to design software. Doing so empowers them to perform their best and increases their productivity. Of course if they don’t choose vim as their editor they are obviously idiots and should be fired immediately.

If writing tests before writing code works for you, great. If you like to build POC code before finalizing the design of a product you absolutely should.  If spooning another developer while you pair program is your thing, then I say more power to you. My personal method of stirring up software inspiration involves staring intently at an uncooked potato for one half hour before writing any code. I call it PDD and plan on selling merchandise and training seminars at a very reasonable rate so stay tuned.