Is Design Dead? (2004)

Then, seeing the speed with which those first X features got implemented, they now request Y features and the cycle repeats.

But constantly measuring feature/release velocity means that things that do not directly benefit new features/releases get de-emphasized, such as encouraging developers to not just implement a feature, but go back to their code and try to disentangle the code they just wrote from any other code they may have stepped on. And it's even harder to get the business to agree to not push out features but instead give time to just go back, look and what's there, and figure out how to make it possible to add the next Y amount of features

There's something intoxicating about being able to have a bunch of teams pushing out new updates, but these high velocities can make it near impossible to revisit something. Hell, I've gone back to code bases on projects I haven't touched in only a few months to suddenly find everything has become riddled with spaghetti code and weird hacks to bypass systems. It works, but each release starts developing longer and longer bug fixing time

Maybe you’re talking about getting something “working” in the larger sense, as in a full feature, made up of lots of PRs, but slowing things down just a little bit and focusing on quality in each individual PR is much easier to budget for (no one notices the extra half day) and buys you a lot of quality in the long run.

Most of the time those business types are correct on this.

The only thing is that once the original team has moved on, then if the code is too complex, it can become almost impossible to change.

How do we break this mold? While this absolutely does happen with some management, it's not all management in my experience.

I am an engineer that's found myself in a management role, and I want my team to do exactly this--don't invest tons of up-front effort trying to guess the models and abstractions we're gonna need. Build, iterate, and we'll clean it up when we know what we don't know right now.

It is blatantly obvious to me that things will be on shaky ground, I have a keen sense of what will break and when. And I'm totally good with that! I put "architect for real" time into the roadmap.

But even still, I get pushback, sometimes a lot of it. Like the idea of shipping functional-but-ugly code is somehow totally unacceptable for some reason (even when it's obvious the "pretty" version isn't even future-proofed or appreciably better). And the excuse is usually "Well we'll never have time to fix it".

That doesn't mean that it's a general rule as I am sure there are plenty of exceptions, but it was still striking. In fact, I think I can say that the places that I have worked that were the most profitable were the ones where everybody agreed that the code base was an absolute mess.

In majority of the cases I have encountered the tech debt is optional to address, the risks around them have varying implications depending on the case and there is no blanket decision to cover them. In most of these cases, it is simply a matter of explaining the business people the risks of taking shortcuts. In the end not every tech debt needs to be paid immediately, and not every tech debt is bad. If the tech debt allows you to make money today instead of 2 months from now, you might very well take the debt and think about it later if what you need is money.

I'd recommend talking to business people and making sure they understand the risks of these decisions, then they will be more in favor of addressing them, in some cases even more than you would do yourself.

I currently work for a company providing "cloud services" to other software shops. Part of what drew me here was that the ethos around how we get stuff done does encapsulate this. The engineering culture is pervasive. Here's to hoping we can maintain that as we grow.

I've been exploring a tool in ruby called packwerk, that helps introducing gradual boundaries within a system (made by shopify). The beauty is that while you can see violations you can still run your code.

Now, my thought process is that identify the core high level boundaries is very important to design a system, so this type of tooling will go a long way.

So far to enforce boundaries you either have nothing, which leads to a design that's just a mess, or you have something strong like go packages, which can slow you down.

Design is super valuable, but there are just parts of the software that have little enough business value or will never be touched again, so nobody cares. I think design being adjusted to business and team needs make sense, but we might not have explored hoe to do it. Also, I noticed it's not something every software developer is good at, which means not everybody can do it

This happens at tech-centric companies that sell software. The biggest, in fact. It's depressing.

In my experience, engineers (I am one too) tend to reach for quick and easy more than correct and hard, and that choice is coming from them, not the business.

There isn't anyone taking care of the code like a tiny bonsai tree, unless there is a consulting contract to do exactly that.

One thing I learned moving from product development to consulting, is that developers that are too deep into engineering organizations usually don't realize how much money per hour they burn doing beautiful coding.

When each hour of coding has a price tag to it, one realizes there is a certain need to map how that value turns into the expected ROI from business side.

Which for the majority of companies whose software isn't their main business, rather a means to an end, e.g. sell shoes, the value of perfect code how it is preached at conferences isn't exactly what will help to sell more shoes.

Just recently on HN: 'Software engineers hate code'[0]

It does seem once every modular part of your system works, it's enshrined as a microservice and forgotten about. Tech debt happens this way.

[0] https://www.dancowell.com/software-engineers-hate-code/

There are certainly many businesses where this is true, but there are also many business where it isn't true at all.

The chunking of 2 week sprints is a natural result of this, where the idea is you get together alot in the first few days of a sprint, plan some loose but defined stuff, iterate on it, come back for a day or two in the middle, re-iterate, and then show your work and plan the next cycle. Work should be introduced in such a way it can be chunked in small pieces like this.

This is why TDD became highly coupled to Aigle/XP by the original practitioners around Agile development. Tests are your first validation of an idea, a way to write code-as-documentation and feature validation, before you actually implemented the thing in the product line. (side note: TDD has bee distorted too, by both "zealots" and the opposition, largely lost its original intent and execution)

The real problem, as I have observed, is that everyone is still waterfall or some version of "waterfall lite" and doesn't actually observe the intentions behind Agile. Its been completely devoid of the meaning behind the original manifesto. Hardly any place follows it in its true form, I feel.

In whatever BS performance review process in your company, are engineers going to be recognized for writing documents, meetings, talking to future and end users?

If yes, engineers will do it. As it stands, in large companies, management just wants engineers to code their life out.

So you end up design focus on things that don't matter, and things that do get skipped over.

Another aspect is that (in my experience / opinion) if you're doing an MVP then it really needs to be as minimal as possible - big enough to give you evidence for your future plans but not comparable to what you eventually hope to build. Otherwise it's hard to adapt or to throw away.

The biggest thing I've found to help in any design work is making sure the engineers really understand the problem they're solving, so they can judge independently if plans they're making are complimentary to it.

Imo lots of people are very disgusted by this, mainly because the (a) concervatives/waterfall-heads are horrified by the idea of launching something no thoroughly engineered, while the (b) evolutionary-design folks never want a clean-rewrite from scratch, they'll cling to that "throw-away version" and try to "evolutionarily" refactor it gradually into what they now know it will be needed (and this always fails).

I like to create classes/methods with little/no/mock implementation to see how it will fit together. If there's something where I'm not sure how it works (third party API/lib I've not used before) I'll get more granular with it.

There's tooling to produce diagrams from code if someone really wants it. But either way my design phase is now usable code.

That being said, I still have to admit this rarely survives contact with actual implementation. It just feels better.

On average, I'd say we have much better design and UX now compared to 2004!

In my career I’ve encountered a lot of projects that have been designed to death; They start with good intentions to do things “right” and then hire a lot of people who do a lot of designs and documents and meetings and committees. Two years later, nothing is done because everyone is too busy designing and re-designing.

At the core of it all is the idea that if you’re not following all of these formal techniques and processes then you can’t possibly deliver anything good.

Relatively inexperienced developers tend to very myopically zoom in on particular qualities that are supposedly good, and explain everything that is wrong with software and software development with the lack of this quality; and everything that is right with the presence of this quality.

Of course this phase can't last too many years, as such conceptualizations don't tend to survive contact with the realities of software development. They'll inevitably encounter undeniably good code written with complete irreverence for their most holiest of ideals, and they'll themselves write bad code despite kneeling at the holy altar of clean code or memory safety or pure functions or whatever. Purism is ultimately a completely untenable position.

Refactoring is inherently not about adding anything. If you're adding things as part of refactoring, presumably it's in the service of removing even more things, such as in consolidating multiple similar abstractions into one. If you find yourself adding lots of new abstractions as part of refactoring, YAGNI applies. But "YAGNI applies" doesn't mean "don't do it", it means "make sure you actually do need it, right now, and not in some hypothetical future."

There's a way to plan ahead for likely futures without adding features, and in my mind that doesn't violate YAGNI. You're not planning for one specific hypothetical future, you're trying to make sure your application is robust in the face of likely changes. You don't actually perform those changes, but you do ask yourself how those changes would work in your current application.

I use the analogy of creating a model bridge for a train set. YAGNI would be looking at the bridge and saying "yeah but what about tanks? What if you wanted to land an airplane on that bridge?" -- until you're literally doing it, just stop. It's for model trains; the end. But going over to the bridge and jiggling it, shaking it, seeing if it makes a weird rattle, making sure it's level, pushing on it to see how it bends, and fixing it if any of those things happen -- that's not really YAGNI. That's making sure it's robust and will last into the future, however you decide to use it.

I might also see the world this way right now because I’m currently deep in data model/migration hell with my current project due to my formerly (and possibly still presently) incomplete understanding of how the system and use cases would evolve over time.