3 ms·

Software projects are development projects, not constructions projects. They are similar to the engineer developing the blueprint for a new machine, not similar

Software projects are development projects, not constructions projects. They are similar to the engineer developing the blueprint for a new machine, not similar to the mechanic assembling it.

ardit33 6y ago
That is a very good point. I think non-technical people can not understand the complexities that go with building new products.
choeger 6y ago
Maybe it becomes time to change that. Less innovation and more repetition could help here. I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. We could achieve such a setup by giving software a lifetime upfront and reimplement it after.
- pbourke 6y ago
  > I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. At the end of your several years, your stack will be “outdated,” so you will need to exercise discipline to resist the pressure to keep up with the trends. I like your lifetime idea, though I foresee some hard choices around choosing that timeframe and sticking to your decision to reimplement when the time comes.
  - Findeton 6y ago
    Some things don't change that much. Good luck deprecating Postgres.
- pornel 6y ago
  Physical projects have a construction phase, because they don't have the luxury of zero-cost copying. If you want to construct two identical houses, you still need people to lay bricks twice. If you want two identical websites, you deploy the same files twice. By the nature of software the "construction" part doesn't really apply. If you only replicate already-designed pieces of software, that's more like creating accounts in SaaS or deploying code to new servers.
- eecks 6y ago
  So then you have a team using java struts, jquery deploying to IBM websphere using SourceSafe as a VCS. Slowly but surely you won't be able to hire new people into the team and your development won't be as efficient as in newer technologies.
- konschubert 6y ago
  I generally agree that using boring technology is better. It makes projects smaller. But what is left is still discovery/inventive work. That’s because in software, anything repetitive gets factored out into libraries and platforms.
hodgesrm 6y ago
That's not entirely correct, given that most software projects tend to deliver new versions of something that already exists. Maintenance releases generally tend to be successful. It's new projects that are hard and often have disastrous failures or cost overruns. I don't think software is unique in that regard. The Berlin Brandenburg Airport [1] and the new SF Bay Bridge [2] are cases in point. The latter included serious concerns about the integrity of the bolts that secure the East end of the suspension cables to its pier. [1] https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Overview https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Ove... [2] https://www.wnyc.org/story/316201-brief-history-64-billion-bay-bridge/ https://www.wnyc.org/story/316201-brief-history-64-billion-b...

Software projects are development projects, not constructions projects. They are similar to the engineer developing the blueprint for a new machine, not similar to the mechanic assembling it.

ardit33 6y ago

That is a very good point. I think non-technical people can not understand the complexities that go with building new products.

choeger 6y ago

Maybe it becomes time to change that. Less innovation and more repetition could help here. I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. We could achieve such a setup by giving software a lifetime upfront and reimplement it after.

pbourke 6y ago
> I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. At the end of your several years, your stack will be “outdated,” so you will need to exercise discipline to resist the pressure to keep up with the trends. I like your lifetime idea, though I foresee some hard choices around choosing that timeframe and sticking to your decision to reimplement when the time comes.
- Findeton 6y ago
  Some things don't change that much. Good luck deprecating Postgres.
pornel 6y ago
Physical projects have a construction phase, because they don't have the luxury of zero-cost copying. If you want to construct two identical houses, you still need people to lay bricks twice. If you want two identical websites, you deploy the same files twice. By the nature of software the "construction" part doesn't really apply. If you only replicate already-designed pieces of software, that's more like creating accounts in SaaS or deploying code to new servers.
eecks 6y ago
So then you have a team using java struts, jquery deploying to IBM websphere using SourceSafe as a VCS. Slowly but surely you won't be able to hire new people into the team and your development won't be as efficient as in newer technologies.
konschubert 6y ago
I generally agree that using boring technology is better. It makes projects smaller. But what is left is still discovery/inventive work. That’s because in software, anything repetitive gets factored out into libraries and platforms.

hodgesrm 6y ago

That's not entirely correct, given that most software projects tend to deliver new versions of something that already exists. Maintenance releases generally tend to be successful. It's new projects that are hard and often have disastrous failures or cost overruns. I don't think software is unique in that regard. The Berlin Brandenburg Airport [1] and the new SF Bay Bridge [2] are cases in point. The latter included serious concerns about the integrity of the bolts that secure the East end of the suspension cables to its pier. [1] https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Overview https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Ove... [2] https://www.wnyc.org/story/316201-brief-history-64-billion-bay-bridge/ https://www.wnyc.org/story/316201-brief-history-64-billion-b...