4 ms·

> Before the 2000s, academics ruled computer science. They tried to understand what "engineering" meant for programming. They borrowed practices from other fiel

> Before the 2000s, academics ruled computer science. They tried to understand what "engineering" meant for programming. They borrowed practices from other fields. Like dividing architects from practitioners and managing waterfall projects with rigorous planning. I don’t think this is anywhere close to an accurate account of history. If you look at the history of “waterfall model” then you find Royce (1970), and if you dig back farther you find Bennington (1956). From their writings, it sounds like people understood how bad the waterfall model was, even back then. The waterfall model primarily shows up as an example of what to avoid. > Developers must ship, ship, and ship, but, sir, please don’t bother them; let them cook! My explanation for this is that corporations are just really bad at building incentives for long-term thinking. The developers who ship, ship, and ship get promoted and move up, and now they’re part of the leadership culture at the company. The right incentives are not in place because the right incentives are too difficult—we want nice, easy-to-measure metrics to judge employee performance. Shipping features is a nice metric, and if your features move the needle on other metrics (engagement), then so much the better. You get retained, you get promoted, because you gave management a nice little present full of data on why you’re a good employee, wrapped up with a bow. The reason that managers want nice metrics is because they want to avoid being blamed. Managers want to avoid being blamed for the wrong decision more than they want to make the right decision. The way to counteract it is to cultivate trust. With trust, you can work on other things besides avoiding blame. When you’re working on other things besides avoiding blame, you can take the long-term view. When you take the long-term view, you can advocate for employees that fix problems and give them resources.

colechristensen 2y ago
"waterfall" is just a pejorative term for the kind of planning represented by a Gantt chart, which kinda looks like a waterfall. This kind of planning is _necessary_ for traditional engineering projects where certain steps of the process can take months or years and requires scheduling of many resources. Purely software projects usually don't need that because if your tools are good you can ship a completely new version in minutes to hours instead of months to years. You also get very easy do-overs if there are mistakes which you don't get if you're building a bridge or a factory.
- deleted 2y ago
  [deleted]
- janpieterz 2y ago
  Waterfall in software development was different than a Gantt chart based "project that was managed" like the construction of a bridge (an example close to my house). They added new requirements to this bridge (like they wanted the surrounding grounds to be maintained nicely, so added irrigation and gardening etc). But no new requirements were added to the foundational "here's a bridge and it needs to cross this stream from this point to that point" (high level). Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. That's where the anti-Gantt and "bad waterfall" comes from, the reality is the software world as a whole moves way quicker and requirements are way more malleable, subjective than building a bridge.
  - colechristensen 2y ago
    >Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. Exactly this same thing also happens in non-software "waterfall" projects as well. Mid-project fundamental requirements changes which result in having to re-engineer large parts of the project. This is one of the reasons military acquisitions are so expensive, there's a huge problem with requirements changes.
    - com 2y ago
      And thus us why large-scale construction companies can bid so low, because most of their revenue and profit come from the inevitable scope and requirements changes later in the projects.
    - janpieterz 2y ago
      Perhaps to some degree, but I've never seen a skyscraper that was almost done being torn down to be re-architected and rebuilt.
eastbound 2y ago
In my startup, for all the future devspeed promised by developers who pretend to know how to plan, after 4 years we sure lack to see their features. I don’t know, it feels like customers buy our product because has features, but who doesn’t like a good K8s stack. The market never seems to end producing those developers who spend their life refactoring and never shipping anything, nor taking responsibility for the fact that their pile of technologies SLOWS DOWN the other developers while never solving the problems they were implemented for. It’s not a manager problem. Developers don’t like taking responsibility for their mistakes.
- deleted 2y ago
  [deleted]
- klodolph 2y ago
  > It’s not a manager problem. Developers don’t like taking responsibility for their mistakes. I’m glad you agree on both of these points. Like I said, it’s a problem with building the right incentives, and a problem with people who are trying to avoid blame. A developer with a good, long-term view has a light touch. On one side, you have reckless developers who ship out buggy products that cause problems for operations and customer trust. On the other side, you have fastidious developers who just keep refactoring everything and never ship features. Sometimes, you find a team that can do both. When I’ve seen this, the team has been made of both types of developers. A mix of skill sets, and a high level of trust that they won’t be blamed for failures (outages, missed deadlines). Your developers who move fast and break things will take the time to write a few tests and break things less. Your fastidious developers will relax their standards a little bit and push out code faster, knowing that their contributions are still valued.
- ethbr1 2y ago
  Related: I don't know why software estimation doesn't spend more time on risk and less time on estimation. How much risk (to delivery) is left out there? What can we do to reduce that risk? It's a known thing, but seems rarely used in software shops. https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model Who cares if 97% of the code is complete, but the remaining 3% is a critical feature, with unclear requirements, that's never been prototyped, and has no test data?
ramoneguru 2y ago
100% agree with the "building for trust". The only problem is we tend to hire based solely on technical skill. I don't recall an interviewer ever asking me something like, "how do you build a team that values trust and what does trust mean to you?" Even when I joined the team, we never discussed trust and what we can do to be a more trustworthy team. It was always centered around how can we be more efficient in our deliverables. This is the video I usually reference: https://www.youtube.com/watch?v=kJdXjtSnZTI https://www.youtube.com/watch?v=kJdXjtSnZTI
turtle_heck 2y ago
> corporations are just really bad at building incentives for long-term thinking. Most corporations are really bad at long-term anything. CEOs want every quarter to be more profitable than the last, mostly everything else is irrelevant.
supportengineer 2y ago
The pay for developers is also decidedly non-linear compared to ability levels. Promotions are famously non-deterministic. Hordes of $300k developers trying to become $500k developers who are trying to become $1M developers.
fny 2y ago
This reminds me of a post[0] where 3 junior devs had written a spaghetti monster that generated 20 million dollars annually, and OP was crying for a rewrite while everyone on HN chuckled. "Long-term thinking"--often times, you ain't gonna need it. "Engineering" also rhymes with "bike shedding". [0]: https://news.ycombinator.com/item?id=32883596 https://news.ycombinator.com/item?id=32883596
RaftPeople 2y ago
> I don’t think this is anywhere close to an accurate account of history. This was my thought also. I've been building software systems since the early 80's and I've never been part of a project that looked like waterfall, but I've also been in small to midsize companies, not large. The approach on projects has been somewhat consistent for my entire career which is just a pragmatic look at the project and approach the problem based on the nature of the specific project. There are some projects or parts of projects that really require up front design and planning (e.g. when coordinating changes in multiple external systems that must all play nicely together) and some other parts of projects where the best approach is to iterate (e.g. we've never done something like this before and can't use our experience to guide us very much so we need to try some stuff). Projects are typically a combination of all of the above and more. When I originally read the agile manifesto my thought was "ugh, ya, this is all pretty normal common sense, sounds like these guys must be working in some large corporations where the bureaucracy has taken over and they are trying to push back."

colechristensen 2y ago

"waterfall" is just a pejorative term for the kind of planning represented by a Gantt chart, which kinda looks like a waterfall. This kind of planning is _necessary_ for traditional engineering projects where certain steps of the process can take months or years and requires scheduling of many resources. Purely software projects usually don't need that because if your tools are good you can ship a completely new version in minutes to hours instead of months to years. You also get very easy do-overs if there are mistakes which you don't get if you're building a bridge or a factory.

deleted 2y ago
[deleted]
janpieterz 2y ago
Waterfall in software development was different than a Gantt chart based "project that was managed" like the construction of a bridge (an example close to my house). They added new requirements to this bridge (like they wanted the surrounding grounds to be maintained nicely, so added irrigation and gardening etc). But no new requirements were added to the foundational "here's a bridge and it needs to cross this stream from this point to that point" (high level). Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. That's where the anti-Gantt and "bad waterfall" comes from, the reality is the software world as a whole moves way quicker and requirements are way more malleable, subjective than building a bridge.
- colechristensen 2y ago
  >Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. Exactly this same thing also happens in non-software "waterfall" projects as well. Mid-project fundamental requirements changes which result in having to re-engineer large parts of the project. This is one of the reasons military acquisitions are so expensive, there's a huge problem with requirements changes.
  - com 2y ago
    And thus us why large-scale construction companies can bid so low, because most of their revenue and profit come from the inevitable scope and requirements changes later in the projects.
  - janpieterz 2y ago
    Perhaps to some degree, but I've never seen a skyscraper that was almost done being torn down to be re-architected and rebuilt.

eastbound 2y ago

In my startup, for all the future devspeed promised by developers who pretend to know how to plan, after 4 years we sure lack to see their features. I don’t know, it feels like customers buy our product because has features, but who doesn’t like a good K8s stack. The market never seems to end producing those developers who spend their life refactoring and never shipping anything, nor taking responsibility for the fact that their pile of technologies SLOWS DOWN the other developers while never solving the problems they were implemented for. It’s not a manager problem. Developers don’t like taking responsibility for their mistakes.

deleted 2y ago
[deleted]
klodolph 2y ago
> It’s not a manager problem. Developers don’t like taking responsibility for their mistakes. I’m glad you agree on both of these points. Like I said, it’s a problem with building the right incentives, and a problem with people who are trying to avoid blame. A developer with a good, long-term view has a light touch. On one side, you have reckless developers who ship out buggy products that cause problems for operations and customer trust. On the other side, you have fastidious developers who just keep refactoring everything and never ship features. Sometimes, you find a team that can do both. When I’ve seen this, the team has been made of both types of developers. A mix of skill sets, and a high level of trust that they won’t be blamed for failures (outages, missed deadlines). Your developers who move fast and break things will take the time to write a few tests and break things less. Your fastidious developers will relax their standards a little bit and push out code faster, knowing that their contributions are still valued.
ethbr1 2y ago
Related: I don't know why software estimation doesn't spend more time on risk and less time on estimation. How much risk (to delivery) is left out there? What can we do to reduce that risk? It's a known thing, but seems rarely used in software shops. https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model Who cares if 97% of the code is complete, but the remaining 3% is a critical feature, with unclear requirements, that's never been prototyped, and has no test data?

ramoneguru 2y ago

100% agree with the "building for trust". The only problem is we tend to hire based solely on technical skill. I don't recall an interviewer ever asking me something like, "how do you build a team that values trust and what does trust mean to you?" Even when I joined the team, we never discussed trust and what we can do to be a more trustworthy team. It was always centered around how can we be more efficient in our deliverables. This is the video I usually reference: https://www.youtube.com/watch?v=kJdXjtSnZTI https://www.youtube.com/watch?v=kJdXjtSnZTI

turtle_heck 2y ago

> corporations are just really bad at building incentives for long-term thinking. Most corporations are really bad at long-term anything. CEOs want every quarter to be more profitable than the last, mostly everything else is irrelevant.

supportengineer 2y ago

The pay for developers is also decidedly non-linear compared to ability levels. Promotions are famously non-deterministic. Hordes of $300k developers trying to become $500k developers who are trying to become $1M developers.

fny 2y ago

This reminds me of a post[0] where 3 junior devs had written a spaghetti monster that generated 20 million dollars annually, and OP was crying for a rewrite while everyone on HN chuckled. "Long-term thinking"--often times, you ain't gonna need it. "Engineering" also rhymes with "bike shedding". [0]: https://news.ycombinator.com/item?id=32883596 https://news.ycombinator.com/item?id=32883596

RaftPeople 2y ago

> I don’t think this is anywhere close to an accurate account of history. This was my thought also. I've been building software systems since the early 80's and I've never been part of a project that looked like waterfall, but I've also been in small to midsize companies, not large. The approach on projects has been somewhat consistent for my entire career which is just a pragmatic look at the project and approach the problem based on the nature of the specific project. There are some projects or parts of projects that really require up front design and planning (e.g. when coordinating changes in multiple external systems that must all play nicely together) and some other parts of projects where the best approach is to iterate (e.g. we've never done something like this before and can't use our experience to guide us very much so we need to try some stuff). Projects are typically a combination of all of the above and more. When I originally read the agile manifesto my thought was "ugh, ya, this is all pretty normal common sense, sounds like these guys must be working in some large corporations where the bureaucracy has taken over and they are trying to push back."