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

There is absolutely shame in "good enough". Mainly that created by weaselly coworkers trying to get ahead and establish technical superiority in the eyes of the non-techie management. These people never write any code themselves but are the first to start WTF'ing really loudly when someone else completes something. Usually the volume and banality of things programmers complain about identify their technical competence, with the bottom of the barrel being complaints about whitespace and formatting. "WTF! Bob put TWO spaces instead of ONE all after method names all over the ENTIRE file! whaaah!" Yes, it becomes this petty with some people.

So a smart programmer will strive for 'quick perfection', establish respect in some other way to counter this, or if they really want to sink that low, fight back with similar tactics. Smart programmers can also create review traps if they can guess what colleagues will attack them on.

Its also good if you beat up another programmer on the first day so the others know not to mess with you ;).

I've often noticed how software is similar to hardware in one way.

Software and hardware are both destined to hit a limit, in any current configuration, no matter how it's built or put together.

Whatever computer we buy, it has a limit. The day will come that the capability we originally had will not be able to power what we need. We decide how much (and how far) to invest into the future to stay on a machine. This can be a benefit sometimes, other times, not. Sometimes we need a computer to be good enough to do a certain task, other times not.

Building software has a similar shelf life. All software, no matter how it is, or isn't architected, will have it's limits because of it. This can be a benefit sometimes, other times, not. When those limits are hit, you'll have to deal with it. Throw more horsepower at it, or refactor.

If there's code that isn't updated often, and doesn't need to be super performant, good will be the same as great code.

When starting a new project, I find myself more and more asking the questions:

- How long will I need this codebase to do what it does? - Will the codebase grow? - How soon/often will it grow? - Will additions be trivial / non-trivial?

Most often I now just start with an ultra lightweight MVC framework to keep my coding semi-organized and primed to re-factor, but not much more. I have a set of scripts that will initialize an entire project how I like and I can quickly start hacking on a new project/idea in a few minutes.

The less I obsess over every small architectural detail and let my decent habits of being reasonably kind to my future developer self, I find myself having fun while being responsible.

yep, I just found myself saying something like this the other day when talking with another engineer about the issues at the current company I work for. Its my belief that modern web application development is primarily about leveraging existing frameworks and libraries to deliver the results, failure to take advantage of an existing resource can cause the project to be much more complex to maintain and waste tons of efforts programming aspects of the project that aren't concentrating on the actual domain problem that is trying to be solved.

"Would an engineer design a small, single lane bridge for a rural Northumberland village so that it could support the weight of a thousand double decker buses? No. So why do we, as software engineers try to do exactly this? That day will never come."

It comes every time a boss or client says "oh, and now we need it to do XYZ. And you can't rewrite or start over. We need it tomorrow. Build on what you have - reusable software is our goal." and so on.

No one is going to go to a bridge engineer after a two lane bridge is up and running, and that took 2 years to build, and say "ok, add 4 more lanes by next week. Oh, and you have no budget". No one in their right mind would ever dream of doing that. But with software we face it all the tim.

Basically, many of us are conditioned to have to extend on top of whatever our first iteration is, so we try to make the first iteration extendable. I'm not saying it's right or good, but I've fallen in to this trap too many times in my career and seen it happen to too many other people to think it's not a contributing factor.

This is the experienced developers dilemma: "To engineer or to not engineer"; engineering usually turning out to be over engineering. A more experienced developer friend of mine would always tell me: "build for today's requirements". I try hard to fight the design/architect voices in my head that always want to imagine this made up future where we will need X or else we cannot go live. These voices usually only stall real actual work, instill fear, and serve very little to no purpose.

I once had an argument with a Wall Street Java developer who was made the "lead" of one of our team projects. He decreed that every single class have an interface so that we can be generic and not tightly couple any of the components to concrete classes. I agreed that in some instances where functionality, i.e. methods that can be represented by different classes with the same method signatures made sense but not every single class needs an interface (if that is the case just go with a beautiful dynamically typed language like Python and avoid the code bloat). He got management on his side and we went off and built an overly engineered Straight Through Processing solution. It was a sheer nightmare to debug and the code bloat made me scream one day when we had a serious production issue. Even our manager (who finally had to look at the code when most of us were out on vacation once to answer some user questions) was flabbergasted at the amount of code he had to read through in order to answer the most trivial of questions. One extreme example was an interface for trade references. Our trade references were always strings with a date and some numeric value concatenated to it. The "engineer" decided that we needed an interface for this and added one interface and concrete class for our trade references. I told him that all classes needing trade references instance variables could just have a String instance variable named tradeReference or something like that and he went on to give me a design pattern lecture. We argued for nearly 20 minutes about this silly thing as he kept insisting that the future was unknown so we have to future proof the code from unforeseeable changes. When he said this I asked him to remove the Crystal ball plugin he had in Eclipse for predicting the future and get real. He got angry and we had a team call to waste yet another hour of developer time to discuss this. In the call I mentioned that our trade references scheme had not changed in 8 years and was unlikely to change... I lost the debate anyway. The ratio for most of the code base from interface to concrete class was largely 1-1 thus not justifying this code bloat approach.

Experienced developers (at least I think) seem to have these crystal balls in their heads or IDEs and usually try to be clairvoyant when it comes down to building a product. We need to get out of the business of overly engineering and just do as my friend said: "build for today's requirements". It is called software for a reason: it is soft. It can change (most likely will), can be refactored, redesigned, and/or incrementally made better or more abstract to accommodate changes. I am in no way saying no design, just limit it and get to work. A successfully built product is more satisfying then the imaginations of your head and the "perfect" engineering/scaling solution that never materializes. Users will like you, you will like you, and the team will get an andrenaline boost with each and every release keeping the spirits high. Remove the Crystal ball plugin from your head/IDE and stop trying to be clairvoyant and be a developer.