Hacker News Reader

I think the type of software that is being written has changed over time. In the past, companies had to write complete software that would be shipped on a CD - you cannot deliver an incomplete product and then change it later. Nowadays, majority of the software lives online and can be redeployed in a short time. Delivering early and often is possible now, but it wasn't in the past for majority of the projects.

Yep, also we're leveraging components that other organisations build more. For instance, we used to build our own messaging systems, now we use open source projects like Kafka. We used to write our own wire protocols, now we use HTTP endpoints with JSON payloads. We used to write our own authentication systems, now we use authentication libraries. Our patterns have standardised to the point that we don't need to design and document nearly as much as we used to.

Exactly this. You never know your problem domain as well as you think you do.

I always try to start a new project assuming everything could change. Paradoxically, this approach tends to produce the same net result as assuming nothing will change. If you have no idea how requirements will evolve over time, there's no point guessing. Just write the code needed for the first batch of requirements, and nothing else.

It is orders of magnitude easier to add a layer of abstraction to a simple system when new requirements demand it vs. remove a layer of abstraction later when you finally realize you don't need it. The latter is often impossible.

Hundred percent.

I mentally call this "dumping all the Legos on the floor".

I think of abstracting as "sorting Legos" and think of the process of writing the minimal code as "dumping the Legos on the floor".

Once they are all on the floor, is easier to sort.

Yes, but one shd decouple if decoupling doesnt introduce cost.

But what was perhaps lost along the way was communicating inner workings through something else than code.

I think UML and its likes still have immense value between developers and teams to communicate complex processes in a way that is easy to understand at a glance and facilitate shared understanding.

Sure, but you don't have to go as heavy handed as UML. You have to wonder if a visual diagram is the best way to go into detail or should we use other ways of delivering that information?

I'd say this is suitable to give to an engineering team, along side a table with some endpoint detail, or even just the swagger. https://v2.developer.constantcontact.com/dotAsset/991381b5-0...

Whereas this is too much information and too hard to decipher at a glance: https://docs.microsoft.com/en-us/azure/active-directory/deve...

Diagram the higher level, leave the detail to other mechanisms.

> Software projects always used to go massively over budget, were delivered late, and usually didn't meet the customers requirements anyway.

I feel like this is still the case under "Agile"

Sure, but agile is about breaking up work into small chunks and showcasing value in those small chunks. If you're doing it properly you'll be able to look at your velocity and know that you're falling behind schedule. Or, your customers will be able to see early that the thing your building doesn't suit their needs.

It means you can plan for and adjust early, rather than the week before a deadline.

Basically, we can't plan and estimate very well in tech, but it's easier to be accurate in our plans and estimates in smaller chunks than in larger.

Saying that, agile is about delivery rather than project management, and there always needs to be a larger roadmap to track features against - which is how we know if we're going to be late or not.

> Also, it turns out that engineering teams know better how to develop a piece of software than architects.

That's not a surprise because of the prerequisite of being a good developer is to...well, write code.

> We solve the complexity problems by breaking a project down into (as he says) "pizza team" size components

The value of carefully-planned design is above the "pizza-team" level - that's the whole point of planning a system "in the large". The 'in the large' bit implies larger than pizza size.

"Getting feedback early and often" can only apply at the level of an individual component.

Sure, but the higher level you go the less detail you need. UML gets right down into the weeds, this is where design as code and documentation as code comes into play.

Plan at a higher level, execute at a lower.

Question. Do you use no diagramming techniques now?

I created an "Ask HN" topic to discuss what diagramming techniques development teams currently use:

https://news.ycombinator.com/item?id=26940593

even with agile processes you will probably need to write some kind of design documents, and chances are that this document will contain more than one sequence diagram or UML class diagram. You still need to communicate with your team members and reach some sort of consenus on what you are going to do and how the service will look like.

Yes, but at a higher level and less formally than UML.

A sequence diagram doesn't need to be ordered in a time sequence like UML, it can be good enough to just articulate and number the flow of information on a normal solution diagram.

A class diagram assumes we're using an OO language - we need to define schemas for data, but not classes. The engineering team knows how to structure their code, as an architect all we need to worry about are the boundaries.