Software design gets worse before it gets better

Infra, devops, and (software engineering) org decisions ARE part of software design. Application layer is not the only consideration worth prioritizing design time over.

Microservices is just a buzz word for an overly prescriptive (thankfully waning in popularity) type of distributed system. When you are developing a distributed system, the infrastructure is a primary consideration that is potentially even more important than anything in the app layer.

Firstly, Hey Kent, how have you been?

Secondly: I think this may be reflective of someone that hasn't sat down and realized the environment that they're in. Creating a poor architecture or approach for the first go is usually a sign of dysfunction or inexperience.

Inexperience: It's more that the individual hasn't sat down, realized that the initial approaches are in appropriate and should be designing first before pushing forward. Experience should be fleshing out a lot of these details before coding anything and get the protocols and conflicts resolved months before they happen. (This is where I see a Staff+ being responsible and assisting in the development of the project)

Dysfunctional environment: Our culture in software engineering has forgone formal design before creating a solution. Typically, most development is dictated by "creating a microservice" first and then trying to design as you go along. This is so aggressive in a coding first approach that many even forgo testing. Why does this exist? Partly the incentives by business/management to deliver fast and distrust in the survivibility in the product.

---

That being said: Am I promoting a "perfect design" (as I've been accused of doing) first? No, iteration will happen. Requirements will change, but if you're applying strong tooling and good coding practices.. rearranging your arch shouldn't be as big of an issue as it currently is.

Needed this today. I think sometimes engineers go crazy and go try to greenfield something, anything, because building stuff requires it being in a nonfunctional state for a sec and this is hard enough on its own but there being (understandable, but often very counterproductive) friction around that that comes from what you're working on being something someone is relying on can make it a really daunting and frustrating process due to the inevitability of the trough

good design and implementation requires skilled people. you don't get either with bottom of the barrel pay grades.

something I have noticed in this industry is that big companies think they can outsource their staffing issues and "save on labor". But in the end they pay more in management of outsourced assets, inevitable maintenance of poorly designed and implemented software, delays in delivery, and of course the churn and burn of hiring/firing contractors. Then they end up redoing everything with local talent with 1/8th the team in half the time.

It only took 3-4 years to realize this but this is what the "trough of despair" really looks like.

It's not a good idea to rewrite working code from scratch. But I've found starting a greenfield project next door to working code often works well.

Not every new feature needs to go in an existing repository. Sometimes it makes perfect sense to implement the new functionality in a separate executable and artifact that doesn't carry along all the technical debt of the old project.