There's no shame in code that is simply "good enough"

This actually causes "coder's block" in me when I start a new project. If I have this cool app or site idea, it often never gets off the ground because I spend too much time trying to create some architectural framework that I assume I need.

This is REALLY bad for me in Cocoa/Cocoa Touch apps. Objective-C is so verbose and writing classes is so "mechanically cumbersome" (having to write .h and .m files and duplicate stuff, for example) that I sometimes lose interest before I ever really get off the ground.

The trick I use to beat this tendency is to totally eschew good software engineering principles at first. Typically all of my code lives in main.m (and I usually start out in CodeRunner rather than XCode). Interfaces are done sloppily in Interface Builder or entirely in code. This really helps me get started.

Before long, of course, I have this unwieldy spaghettified mess of a single source file. By that time, though, I have some stuff WORKING, so doing some refactoring into a good architecture for the code I have while keeping the working stuff working is kind of fun.

"Perfect is the enemy of good enough; good enough is the enemy of all." [1]

There's no shame in code that's 'good enough' but I think there's a danger in this article of missing an important point: you can't classify your output if you don't know its context and goals. If you're coding something that definitely won't be used again then make it 'good enough' for this use case, if you need it to be extended by others over the next few months then make it 'good enough' for that use case, if you have a contractual obligation to get it out to the client 'now' then stop thinking and start doing!

But paralysis is costly. If you lack the required knowledge to take a sensible decision, then take a gamble: never hold up making a low-risk choice because you don't know enough. The opportune time to learn what the right choice was is once you've made it and can evaluate the outcome with data.

The other thing to note is that complexity on its own isn't bad, complicatedness is [2]. The knowledge you've gained shouldn't be making your code more complicated. You should spend your time on creating an arsenal of simple solutions to complex problems. That is perfection (and you will never reach it.)

Optimize your time by evaluating after instead of planning before; over time create simple solutions to complex problems and use these as shortcuts to act decisively.

[1] http://paulbuchheit.blogspot.com/2007/04/perfect-is-enemy-of...

[2] http://usabilityworks.org/2006/12/13/simplicity-complexity-a...

> Say you are throwing two outdoor parties a year, but otherwise will not serve more than 8 people. The best solution, if you start with nothing, is to buy a set of dishware for 8, and then throwaway plastic cups and plastic knives twice a year ad hoc.

Not really. Only if you've no time to look for good dishware (surprise party?), can't afford it this instant (or fall in the common pit of not doing the math for the long term) or you absolutely do not have space for the “extras”, which is fairly rare.

To extend the metaphor, this “disposable” code tends to end up in unexpected places and stick around polluting the ecosystem forever.

Or, like some people, using disposable stuff every day and probably having trash all over the house to show for it.

…

That said, disposable code is fine. The metaphor isn't exact, but does point to some things to be cautious of.

It's a nonstandard definition of optimization in many of these case but I still feel like this all falls under "Premature optimization is the root of all evil"

Also importantly apparently the full(er) quote is "say about 97% of the time, premature..." Because even Knuth knew that sometimes you should design for that herd of buses.

I still experience the drive to "over-architect" a solution every so often, especially when starting a new project. For me, it tends to be a result of thinking, "oh, I can add that additional feature with little impact to the timeline of the project." I have to force myself to remember the mantra: You're Not Gonna Need It. More often than not it ends up being right.

http://c2.com/cgi/wiki?YouArentGonnaNeedIt