I am frequently confronted by a dilemma while working on new projects — that is, writing new code and designing new architectures. The whole time I’m designing the architecture I think of how much better it could be solved for a more general case. There is a constant temptation to step back and think of the problem in a new light, molding the solution to be even more useful for similar problems and future uses. This leads to a tug of war between refactoring the current project’s architecture while I’m writing it and just writing a one-off to come back and refactor later (like that ever happens). I feel like I’m sliding down a slope while trying to plant my feet to regain control.
Like most things, the answer lies with neither of the extremes; there is a balance to be found. Stopping all work completely to write the One Framework to Rule Them All is obviously not an option when you have competitors, profits, and more projects to worry about. It is also unwise to write the quickest thing possible and get it out the door so you can move on to the next project. Poor architectures come back to bite you sooner or later, whether that “you” is the author, the company, or a user; it doesn’t matter much in the end.
A short digression into the unholy world of one-off hacks is in order at this point. There is a time and a place for writing careless, terse, obtuse code that just gets the job done. The time for this strategy is not, however, in the course of normal business on normal projects. Obviously “normal” can be traded on quite freely, but the point is that developers who are hacks (in the bad sense) will always decrease the net worth of the team, the products, and the company as a whole over the long run. All good developers feel queasy at best when implementing a hack solution on real projects and any who don’t should be relegated to writing spreadsheet templates for the marketing team.
Back on point: designing for the general case or at least being prepared for a more general use of a single implementation is part of being a good developer; knowing when to stop the architecture and finish the project is part of being a great developer. Code should be well-designed enough that it is less than painful to reuse it or integrate with it later. That said, there are several tools built to help you in this situation. More recently, frameworks like Django, Ruby on Rails, and Catalyst have been created to help with precisely this problem. Some of the main ideas behind a model-based framework are modularization and simplification of code. In effect, these frameworks gently persuade you to architect just the right amount, making future interactions with the code painless, or (gasp) even enjoyable.
Dictionary.com
No results found for architecting.
Well aware. I retain the right to create words when I feel it suits me. :)
I’ll keep an eye out for that h3h english revised edition ;)
I would like to include your blog posting, Education and the Internet, at the Kierkegaard Carnival. Please see the announcement for the first edition of this carnival at The Cynic Librarian.
I agree a line must be drawn. Analysis Paralysis is a real danger.
Often times continuing with a less than perfect architecture gives valuable experience for when the time does come to do things differently.