Live data from Hacker News

Importance of Conceptual Integrity in System Design

wiki.c2.com

1–10 of 34 posts

Re: Importance of Conceptual Integrity in System Design

#3
Even with a single mind having the final say over the design, it is still easy to violate conceptual integrity in software if it directly or indirectly touches the end user or “real world” in general. In this case, requirements or their understanding will inevitably change, and any time that happens in order to maintain conceptual integrity software has (effectively) to be redesigned[0].

If you’re lucky, the result of that redesign might turn out to be close enough to what you currently have[1]. What’s dangerous is skipping that taxing redesign process altogether, or losing sight of the new target while you strive to maintain software built on the now-outdated conceptual model in order to address users’ current needs faster. Keeping in mind the updated model and evolving the whole system towards it while continuing to provide functional software to existing users at all times is probably the most difficult aspect of building software for the end user.

That said, I agree that originating from a single person (or indeed very few “agreeing resonant minds”) might be a pre-requisite for cohesive design, and I think “conceptual integrity” is a very fitting term.

[0] This might sound drastic, but this is my belief so far. Slightly expanded on it in https://news.ycombinator.com/item?id=25408650.

[1] I am tempted to say that the “tighter” the design (the more tailored the solution is to the problem), the more likely a small change in requirements is to affect the product in a major way once you rethink it.

Re: Importance of Conceptual Integrity in System Design

#4
Conceptual Integrity is hugely important, but a system architect is neither necessary nor sufficient for achieving it.

One person's system designs can lack conceptual integrity as easily as someone can make a plausible logical argument which lacks conceptual integrity.

If a design is to maintain conceptual integrity, the people who maintain it are responsible for it. That means everyone.

Re: Importance of Conceptual Integrity in System Design

#5

Conceptual Integrity is hugely important, but a system architect is neither necessary nor sufficient for achieving it. One person's system designs can lack conceptual integrity as easily as someone can make a plausible logical argument which lacks conceptual integrity. If a design is to maintain conceptual integrity, the people who maintain it are responsible for it. That means everyone.

If everyone is responsible then nobody is.

Re: Importance of Conceptual Integrity in System Design

#6
post #5

Conceptual Integrity is hugely important, but a system architect is neither necessary nor sufficient for achieving it. One person's system designs can lack conceptual integrity as easily as someone can make a plausible logical argument which lacks conceptual integrity. If a design is to maintain conceptual integrity, the people who maintain it are responsible for it. That means everyone.

If everyone is responsible then nobody is.

This is true in situations where there is no social contract for the event at hand, like emergencies and other one-off situations. It doesn't apply where there is a social contract. Everybody is responsible for obeying the traffic laws, for example. And everybody can be responsible for maintaining conceptual integrity.

Re: Importance of Conceptual Integrity in System Design

#7
Brooks’ book seems like it is percieved as a software engineering classic but it’s mostly about the management side of things.

Companies are very hierarchical so of course it makes sense for managers that most things should ideally come from one mind or a few agreeing minds. Then the average developer just have to do the grunt work.

So why is the book popular among developers? Because there is an elite cadre of developers in Brooks model which do have autonomy. I guess that cadre might also be known by other names.

[1] And the big man-month lesson of the book should be much more obvious now than it might have been back then: as you add more cooks you also have to take into account the communication overhead among all the new nodes.

Re: Importance of Conceptual Integrity in System Design

#9
> the architect(s) must be egoless

Yeah, and 'the bird(s) must be wingless'. Whoever wrote this is not an architect, nor has ever met any real architects worthy of the label. Architects are driven by an overwhelming imperative to 'order' everything around them.

Also there is a reason we have "egoes". It's not a useless function of the psyche. The problem is with problematic egoes, fragile egoes, over-reaching egoes, etc. A strong, healthy, ego servers a respectable purpose.

Everybody considers themselves a designer, but it is baseless optimism that is supported by little data or precedent. Good designers are unique. Design ability is a 'talent'. Being able to conceive a complex system that maintains "conceptual integrity" is not an ability that everyone has, nor is it show (yet) that is even teachable!

Now an "egoless manager". That is a topic worth discussing. That species was never intended to take to the skies. /g (Bad managers let their egoes get in the way of actual talent, again and again. They should just manage the process and leave technical design for the architect. :-)

Also, yes it's true, you don't always need an architect. Most systems are an instance of a handful of widely repeated system patterns. What most teams need is a bit of maturity to distinguish and select the appropriate ready-made blueprint for their project. It is highly unlikely that your project requires a 'conceptual' breakthrough or innovation.

Post reply on HN