Architecture Last

I recently read this article, “Architects Need a Pragmatic Software Development Process”, and something bothered me about it. I admit I have a kneejerk reaction to the idea of a “software architect”, or at least my interpretation of their role. I don’t envy someone who’s job it is to create solutions for problems before they exist in a way that’s supposed to be globally usable.

The article in question uses phrases like “architectural recommendations”, “non-functional requirements”, “UML models”, “bibliography” and other phrases that just don’t jive with my idea of an optimal development process. The article goes on to recommend that not only do teams have to have a specific iteration-based software development process, but there are software architect components that need to be superimposed on top of the team’s normal development practices.

How about code first, architecture later?

For me, architecture (at least from a system or company-level perspective) should be one of the last things to emerge from a codebase. I emphasize emerge because that’s exactly how it should work. Following the tenants of “lean development” and “You Ain’t Gonna Need It”, making things into an extensible framework or adding things for the sake of adding them before you have an actual code-based or requirement justification does nothing but inject additional overhead and waste precious development time.

I’m not saying that you shouldn’t be looking at existing solutions both within and outside of your company’s codebase. There’s really no point in reinventing the wheel for such common components as data access, logging, UI, and more. But you should be bringing them in when you decide they’re required, not because an architect told you to. If your company has a really solid data access layer built around SQL Server, and you’re using SQL server in your project, then by all means go for it. If you’re using the company’s DAL because everyone else is, without objectively looking at your application’s requirements, then you’re doing it wrong.

But, the maintainability!

Of course there’s companies that use the same framework / architecture because of a maitenance “non-functional requirement” – if all projects use the same architecture, it’s simpler to hand off the application to another team to support it or to move developers between projects. To this I say two things.

First, if you lock yourself down at such a fundamental level you’re immediately stifling any sort of creativity or flexibility of your developers. Your developers could become stagnant – there’s no reason for them to stay up to date with technology if they’re not able to use it. And if they’re not required to research new solutions or approaches to problems while at work, you’ve effectively reduced them to code monkeys (“Type this boilerplate code in, you don’t have to think”) and your work environment is going to suffer. Good developers have left companies because of this.

Secondly, your applications will become stale and only be able to effectively address one set of problems – as soon as a new client or the industry presents a new problem, it will take your developers and your framework much longer to be able to address it. Companies that are “more agile” than you will be able to roll out new solutions because they are not burdened by having to bake everything into an existing framework layer. They will be able to quickly use new technologies and solutions, and climb above everyone else.

Solve the problem you have

The act of building such large-scale, “solve everything” projects before they’re actually used in an application seems silly to me. I much prefer building a project-specific solution to solve the project’s problems, and then, if other projects can use the solution, looking at refactoring it into a reusable cross-project library. It’s far more effective to solve the problem you have than it is to attempt to solve the problems you think you might have at some point in the future. Of course, this requires a pretty good working knowledge of the solutions that your company and the dev community at large have available, but 4 hours of research will always be less than trying to jimmy in and then support a solution that doesn’t match your needs.

Back to the article for a minute. There’s a whole part that focuses around wiki-based documentation and an entire document lifecycle that I’m not really a fan of but I won’t get into (executable documentation or GTFO). And then it confuses me because near the end they say “[architects] actually believe more in the Programming Motherfucker philosophy”, which seems to be enitrely the opposite of the whole “you need this process and these documents in order to write code” theme the entire article has.

I could go on, but instead I’ll summarize the general idea of this post – You Ain’t Gonna Need It. Write the code you need to solve the problem you’re currently addressing. Don’t write code for problems that don’t exist yet, especially problems at a company-codebase level – they will almost certainly be wrong, and will result in either people not using it, or wasting time trying to get it to work the way they need it to.

Comments