Re: Why software design matters

1

Responding to this post Why software design matters • Buttondown

Professor Jackson asks why software designers focus more on cool new features rather than fixing serious design issues with their existing software that would be more beneficial to the company in the long run.

I think there are many aspects: technical, organizational, and psychological.

From a technical perspective, our tools are often easier to use to build new systems rather than maintain existing systems. And because of the current state of programming, our systems tend to grow large quickly, making their maintenance harder.

From an organizational perspective, are employees rewarded to ship new visible features or fix conceptual bugs? Are employees rewarded for finding these conceptual bugs? I have worked at companies who value conceptual integrity and have processes in place to ensure it is maintained across all their software. But this is rare in the industry.

Finally, I think the psychological aspect is the most interesting but may be the hardest to fix. I think most software engineers have a tendency to prefer solving well-defined bounded problems rather than exploring and identifying real problems to solve. It is more comfortable to think you know what problem you’re solving rather than having to be curious, make hypotheses and test them.

For the same reason, I believe that many software engineers don’t like debugging. They can’t start debugging assuming they know what the problem is. They understand that they will have to make observations, make hypotheses and test them. Once the real problem is identified then the work of fixing it is often a smaller part of the process.

When building new software, we’re not forced, like when debugging, to deal with the existing problem. So we prefer assuming we understand the problem and go on to the fun part of making something.

Software design, and concept design in particular, matters because it allows software designers to make those high-level hypotheses about the problem they’re trying to solve, test them, and iterate on them. Because of our current tools, we can’t wait for the whole system to be built to be able to test it.

1 Like
2

@benfle This is very insightful. One of the things I find interesting in your analysis is that you make the assumption that strategic decisions about what features get added and what gets fixed are made by individual software engineers, and aren’t coordinated by senior designers who have a longer-term and broader view of the product.

This assumption seems correct to me, but maybe it gets to the crux of the problem: that the distributed nature of software development in many companies, while having some advantages, is an obstacle to a coherent design vision.

3

Hi @dnj, yes, my answer was a bit over-indexed on my current situation :slight_smile: .

I think the situation is different in many software companies where business/product people decide what needs to be built. I think there are forces there as well that makes it difficult to solve real design issues: pressure from a big customer wanting a feature, pressure from sales to add more features to win more markets, pressure from leaders when they have a pet project, pressure from the market (“we need to ship AI in our app!”)…

I agree that the easiest way to maintain conceptual integrity has been (so far) to have a senior designer responsible for it. We have at Stripe what we call product architects who play this role. There are some scaling issues though.

4

Hi @benfle, I didn’t mean to imply at all that you were “overindexing”! On the contrary, I think you’ve hit on a fundamental truth that distributed responsibility for design can hurt conceptual integrity.