Hacker News Reader

Comment by onion2k | Hacker News Reader

The "source code is the blueprint for software" analogy doesn't work because the source only tells you what the application does, not what it's supposed to do. There is no way to tell, from the source code alone, whether or not what's been built is fit for purpose. You have to have some other document. The "specification is the blueprint" analogy is saying that the specification is a high level document that sets out what the application is meant to do.

As an example, imagine you're paid $1m to assess my super awesome new database. I give you the source code and tell you "the source is the blueprint." After reading through the code you discover there's no DELETE function. Have I built a clever immutable data store, or am I just an idiot who forgot a critical function? You can't tell that from the source.

View on HN

I agree with you both.

Technically the source is a blueprint. But this comes down to scale.

Among other things I've worked on banking and corporate management applications. You cannot reason about the codebase at that scale. In these instances it's not possible to have a good outcome without a blueprint.

Using the building metaphor, you can get away with building a bird feeder without a blueprint. You can't get away with building a skyscraper without one. Houses, maybe. Either way, high level blueprints help everyone.

Good points - I think you need some kind of spec or something to reason about. But I don't think it needs to be complete because it is easier to iterate on software than buildings.

Taking the building metaphor, you can't clone a building locally and make changes to it, then ask another builder to review them, suggest some changes then push them out to a test environment before finally putting them into the real world. So for me, the building metaphor only goes so far but there are definitely some useful points in the article.

> you can get away with building a bird feeder without a blueprint

Definitely. But anyway, unless you have built several bird feeders or similar constructions before, your first version will probably be ugly and you'll have to iterate on it (i.e. find the right angles etc.) to make it better. What is of course fun, but costs you time.

I cannot tell that from the database, sure, because a database is simply structural information, not functional. Without a list of things that the database is supposed to do, it might be great or it might suck. Don't know.

But all modern systems have both structure and behavior. For every database there is a MVC model somewhere, for instance. And looking at those controllers, you should absolutely be able to tell whether the database is well-constructed or not.

Now there's another consideration: does the database structure map into some problem domain such that the introduction of new controllers will be supported? That's usually what people mean when they talk about architecture: the mapping of a problem domain over to a solution domain such that changes in the requirements have minimal impact on the solution.

In System-of-Systems work I'd argue yes, such work has some value -- as long as it is continually driving some kind of delivery (and not just "smart guys drawing boxes"). But in regular green-field system development? Not so much. That's because the tendency is to begin focusing on the wrong thing, the model instead of the user. Timeboxes help with this, so much so that I wouldn't advise any stand-alone architectural work in such an environment without team integration and time-boxing.

The analogy still holds.

If I hand you a blueprint for a skyscraper and I realize there is no lock specified for the front doors. Does that mean it's a lockless skyscraper or I'm speaking to a jackass who forgot a critical function related to security? You can't tell from the blueprint.

If a specification is required to be 100% complete for all things that could possibly relate in any way, then even blueprints don't qualify.

Reply on news.ycombinator.com