7 ms·

The reason we stopped with UML and other front heavy planning methodologies is that what we planned was always wrong. Software projects always used to go massi

The reason we stopped with UML and other front heavy planning methodologies is that what we planned was always wrong. Software projects always used to go massively over budget, were delivered late, and usually didn't meet the customers requirements anyway. It turns out that customers don't know what they want, or at least can't articulate it properly to business analysts. By delivering early and often, we're not only releasing value to our customers early and often but we're getting feedback, allowing us and the customers to go on a journey of understanding their needs. Also, it turns out that engineering teams know better how to develop a piece of software than architects. We solve the complexity problems by breaking a project down into (as he says) "pizza team" size components and focus on defining the interfaces between those components, rather than go into the weeds of how information flows within the code. This leads to other complexities, of course, but they don't lead to the same sort of delivery problems that large, monolithic designs have. All in all, a switch away from a design heavy approach has improved delivery, value to our customers, and enabled staff to be more productive.

suzzer99 5y ago
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.
- nightowl_games 5y ago
  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.
- andi999 5y ago
  Yes, but one shd decouple if decoupling doesnt introduce cost.
emperorcezar 5y ago
> 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"
- disordinary 5y ago
  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.
Oddskar 5y ago
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.
- disordinary 5y ago
  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-0917-4799-b76a-b87f45a9d9f0.png 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/develop/media/v2-oauth2-device-code/v2-oauth-device-flow.svg https://docs.microsoft.com/en-us/azure/active-directory/deve... Diagram the higher level, leave the detail to other mechanisms.
FinanceAnon 5y ago
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.
- disordinary 5y ago
  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.
zozbot234 5y ago
> 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.
- disordinary 5y ago
  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.
MichaelMoser123 5y ago
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.
- disordinary 5y ago
  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.
edem 5y ago
> 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.
cies 5y ago
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 https://news.ycombinator.com/item?id=26940593

suzzer99 5y ago

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.

nightowl_games 5y ago
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.
andi999 5y ago
Yes, but one shd decouple if decoupling doesnt introduce cost.

emperorcezar 5y ago

> 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"

disordinary 5y ago
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.

Oddskar 5y ago

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.

disordinary 5y ago
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-0917-4799-b76a-b87f45a9d9f0.png 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/develop/media/v2-oauth2-device-code/v2-oauth-device-flow.svg https://docs.microsoft.com/en-us/azure/active-directory/deve... Diagram the higher level, leave the detail to other mechanisms.

FinanceAnon 5y ago

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.

disordinary 5y ago
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.

zozbot234 5y ago

> 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.

disordinary 5y ago
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.

MichaelMoser123 5y ago

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.

disordinary 5y ago
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.

edem 5y ago

> 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.

cies 5y ago

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 https://news.ycombinator.com/item?id=26940593