Ryan O'Neill wrote up "Your Architecture Sucks and I Don't Care," basically pointing out that the best is the enemy of the good. His commenters have absolute opinions: they take his statement as meaning that if the architecture isn't perfect, it's horrible. He's right, they're not.

...In my startup before I began Friendly Dingo, I was obsessed with architecture. I wanted my code to be the cleanest code anyone had ever seen, and I wanted every file, dll, and class to be follow every coding standard you’ve ever heard of.  And it was, it was great.  But my products came out slow, and I spent more time tweaking my code structure(that nobody else ever saw, btw) then I did responding to customer requests for features.  The end result was mediocre product reviews and slow sales.  But man, was my code beautiful.

(FriendlyDingo is a product that says it's going to speed up .Net page deliveries, incidentally - it says via a few config entries, but that doesn't sound like something that needs an architecture to me.)

The point is valid though. focusing on architecture instead of deliverying code isn't a good idea; if the app works, nobody cares (much) how well it's written. Sort of.

One commenter had this to say:

What about when you need to enhance, maintain, scale add features, hire other developers to work on said code, etc. Aren’t those decent enough reasons to care about what the codebase looks like? I’m not totally convinced that you’ll be able to add new features that YOUR customers may want or need in a messy codebase. In my experience if the code is crap the product usually is too. Making changes and adding features, maintenance and training new devs all become a horrid nightmare that have robbed YEARS of my life (that I ain’t gettin back). I’d have to say that there is a line between total chaos and over-engineering. Can’t we all just code along?

Emphasis mine - but this comment is an all or nothing thought. If the architecture isn't perfect, or its goal isn't to be perfect, it's clearly bad architecture and will be impossible to maintain. The blog author disagrees, and points out that he was talking about the perfect architecture, not decent architecture.

How would you measure whether an architecture was good or not? How would you measure whether it was "perfect" or "good enough?"

Not to state the obvious, but there's no such thing as "perfect architecture." The requirements today definitely aren't the requirements of tomorrow. No matter how hard we "aka developers/architects" try, it's a "best guess". Sometimes our "best guess" is very good and other times it's really bad. As any seasoned developer knows, often times the requirements don't exist at all. Even with agile/extreme style development, often times it requires several iterations to "discover" what the requirements should be. The sensible goal is to do your best with the available information and divorce yourself from the solution. This way, if you discover 5 months into coding the requirements were totally wrong, you can quickly change course.

Yet this is primarily what the author talks about when he reminisces about his days as a software over-engineer.  The commenter has (or at least conveys) a better understanding of what architecture is.  It is the overall plan for how your software will be maintained, tested, split between developers, scale, evolve, and be configured.  This list could probably be longer, but for illustrative purposes, it's not hard to see how ignoring (or just royally screwing up) any one of these, will probably grind the project to a halt by the 2nd or 3rd release, when the feature to bug ratio goes to 1 feature for every 100+ bugs.  Sadly this is the state of most commercial software products, even the ones from the big guys.

It's hard to distill software as a business down to coding metrics.  Timing, mind share, and marketing are all terribly important and not tied all that tightly to how good the code is. However, I think feature/bug ratio is probably the best single one since it captures both software quality and how well it can evolve to meet customer demands.  I also don't think it's particularly important to quantify it tightly.  Anywhere from 1:1 to 1:20 is probably okay.  The most important thing is that it stays consistent across releases.  If you can manage that, then it's a good sign that your architecture was good enough since your product isn't drowning in mistakes of the past.

Posts like that pop up every year or so.... It's obligatory "I developed something crappy, and look, no one notices".

I think the ability to follow strict coding guidelines and generally maintain tight engineering discipline on the project is absolutely minimal requirement for any serous software developer. It's like arguing that a novelist should know the grammar... well, duh...

Architecture is obviously an overused term. Over-architecture and associated architectural paralysis are the first signs of essentially not understanding what a software architecture is in the first place. 

--

Nikita ivanov

<a href="http://www.gridgain.com">GridGain - Cloud Application Platform</a>

> "I developed something crappy, and look, no one notices"

Classic.

How would you measure whether an architecture was good or not?

IMHO, architecture is multy level:

First there is the "construction architecture" of a piece of software; The commonly accepted best practice here is a layered architecture with at least the presentation, business and data-access layers plus zero or more proxy/wrapping/isolation layers in between depending upon the needs to insulate from a particular technology.

Second there is the "deployment architecture" where aspects like reliability, scalability, etc are adressed. The best practices here rely upon the use of technologies like web-server/database replication (reliability), distributed database/cache (scalability), JMS/ESB, etc.

To know if construction architecture is good or not: If, while explaining you architecture to a coworker, you see that he is grasping it with ease or even he is leading your explanations then your architecture was probably good enought.

To know if your deployment architecture is good or not; do the same with your client and your client's IT team.

How would you measure whether it was "perfect" or "good enough?"

IMHO, you can't until the software is in production and eavily used !

These are 2 features I want to see in a good architecture:

- The ability to reason about the system, without needing to know all the details. If you need to know the details all the time, it is going to slow you down. A good smell (rotting corpse) indicator is how interfaces are set up. If they contain all kinds of implementation details, you know you are in a world of pain.

- Not carying more weight than strictly necessary. The more weight you need to carry around, the slower you go. The problem is that it often is a gradual process and that certain fundamental choices of the architecture are never reconsidered to see if they are still valid.

tdd(red, green, refactor) with automated acceptance,unit test, gets you what is needed, and puts you on the way to building your beautiful/simple/perfect design/architecture.

No wonder he is slow to put out new products, confusing "clean code" and "architecture."

It took me 20 years in the business to fully realize that architecture does more harm than good. It does NO GOOD. At all. Main reason? It means N things to N people.

What matters is finding good abstractions and have decent implementations of these. The rest always follows.

Seems like the classic business plan velocity vs. technical debt debate.

With so many good opensource frameworks as mature realized patterns out there architecture is less of an issue.  Level of code quality as seen in decoupled/cohesive abstraction can increase short -term development speed (better for business) and long-term code maintainability if you start writing your code to be testable and then unit test your code. 

Sucky code really sucks.  Sucky code that has repeatable unit tests sucks less and helps you think in terms of suckless code.

Its pretty simple, IMO, code/prototype fast with an idea of an architecture you want to provide.  Get your products out the door.  In the meantime, your testsuite is building up more and more, which allows you to more easily go back and redesign things (even from scratch) as you have the seasoned testsuite to stress your new code.

Your users don’t care about architecture, they only care if your app works.

Its definately a good way to start the new year with such comedy.

When "Quality" is a second priority even though its paid for.

Ahh that looks like a Ferrari , oops under the hood it was just a plain old suzuki! Come on!!

What should I do with the Ferrari in the woods?

Or .... even on road:?

http://blog.carwallpapr.com/2010/08/number-5-ferrari-458-on-fire-watch-a-ferrari-burn-down-to-the-ground-a-burning-ferrari/

Actually, the point is the Regular End Users and the Software Developers have different expectations from software, therfore, they have also different Views and Measures for the Quality of Software.

Best Regards,

Sergiu

I think it will be a lamer for a Software developer to suggest that the quality he is providing is not what the business requires. Why do we then actually do software development?

If nothing is aligned then the roads are not the same and no junctions between them.

Well software quality has many dimmensions and different persons are particularly interested for some particular ones:

1. A developer would think:

Software quality means easy to read, easy to maintain, easy to extend, ... the Sex Apeal of the GUI is not my Job

2. A Product Manager or a service provider would say:

Good quality is what sells good and creates few troubles (e.g. low to medium exploitation costs)

3. And End User would say:

Good quality means: Reach functionality, Intuitive,  Fast, GUI & usability!

4. So what is a good quality and successful software will have to point over all dimesions ....

Anyway, these quality dimmensions are independent from each other:

Maybe SAP and Windows are the best examples in this direction.

Software enginers say, SAP is a crap, but is still a Monopol on the market.

Same with Windows. many software engineers would like to work on Linux, but they are still more productive on Windows.

On the oder Side, if you are aiming at creating a perfect software, you will never make money out of it ...

As in many other real life examples, a good compromise (cost - quality - time to market) is the most succesfull solution.

Ahh ... and let's not forget about Nokia losing their leading position on the Smartphone market, after being pioneers and inovators in this domain.