4 ms·

> instead of sitting down and figuring out the actual requirements first like any real engineering job If it were so easy, then we would have done it already t

by bmn__ 7y ago

> instead of sitting down and figuring out the actual requirements first like any real engineering job If it were so easy, then we would have done it already that way for the last seven decades. The simile topples over upon further contemplation: civil engineers: • client is not a domain expert • to an overwhelming part, client needs are easy to transport into the mind of c.eng. • can employ a wealth of standard solutions refined over the course of milleniums software authors: • client is a domain expert for the subject matter that the software is supposed to model • to an overwhelming part, client needs are difficult to express and transport into the mind of s.auth. • if a standard solution exists, the client would have already bought it off the shelf, so coming to a s.auth. always means customised development • the entire sector is still in its proverbial baby shoes We have to come to grips that we unfortunately can't apply what happens to work well for a different sector. The supposed value of non-traditional software methodology lies in that at least the client notices that the requirements are off the needs rather early.

clarry 7y ago
I agree it's not easy, but instead of trying harder to become good at it, it seems like this industry in its proverbial baby shoes threw a tantrum and decided that it doesn't want to learn at all. So instead of pushing for more effort & skill for up-front planning and modelling of the requirements and design (and trying to employ modelling tools & formal methods), we're just like fuckit nah let's just implement something and see where that leads us. It doesn't help that so many of the up-front design failures were not examples of engineers screwing up but sales people selling shit and then having engineers cook it. We'll be stuck in baby shoes for a long time with this approach.
- vinceguidry 7y ago
  Companies are more than happy to churn through staff, losing millions in accumulated human knowledge, just to keep it out of the hands of employees. My company just shut down an entire office, they offered three out of four critical employees the opportunity to move to Atlanta. They didn’t want to move, opting to retire instead. Company just shrugged their shoulders rather than letting them work remote, gave them like a month to transfer knowledge and that’s that.
- mewpmewp2 7y ago
  Didn't we start by trying to plan ahead? There's a reason we have moved to agile. In software if you know what you are doing ahead of time you are not really innovating and you might as well be using an existing system. Since everything that is standardised you can just use as libraries. When building bridges, you can't just use a library that's .buildBridge(...parameters), even though similar things have been done thousands of times before. With code, if something is done enough times that you know how to plan for it, it is likely already a library. You can plan building a bridge since you have done that and have experience of it thousands times over.
  - clarry 7y ago
    > Didn't we start by trying to plan ahead? There's a reason we have moved to agile. "Everything was waterfall and then came agile" is myth, but yes, it looks like it's fashionable to no longer try to plan ahead. I'm not convinced the reasons are good, and I'm not convinced the craft of planning ahead was ever perfected to the point that anyone could say it doesn't work. Scrum, XP, Agile all date back to the 90s when one server running PHP or Perl (with SQL injections) passed for software and others were still re-inventing basic data structures in C (and then gasp C++ with templates!) from first principles... The methodology, tooling, rigor, and collective experience in software development has taken leaps in the past two to three decades. Likewise, understanding systems and planning ahead has become so much easier. If only people took it seriously and spent as much effort on it as they spend on fad-of-the-year frameworks. People just stopped trying, and when I look in software projects now, there's hardly ever anything resembling a model of the software that you could use to test new ideas "on paper" to see how they fit the given problem and current application. People aren't even trying, just like they aren't even trying to achieve correctness: https://news.ycombinator.com/item?id=22224054 https://news.ycombinator.com/item?id=22224054 The less you try, the harder it will be. > In software if you know what you are doing ahead of time you are not really innovating and you might as well be using an existing system. I think the vast majority of software is boring and not even meant to be innovative and indeed would be best written using an existing system, but customizing these to the specific needs is just another can of worms. As with bridges, you can't just copy & paste an old bridge to a new location and use it as-it is, you need to design it given the locale and other constraints. It's still probably going to be yet another relatively boring bridge with no innovation. And indeed a lot of software work is all about using existing systems, but perhaps at a lower level than you posited. Customizing complete off-the-self packages does happen, but it's more common to glue something "new" (but not innovative) using existing frameworks, libraries, services and glue languages. You still need to design to do it right. But even here people seem to rush ass-first into whatever kit looks fashionable now.
- moron4hire 7y ago
  We tried all that. Formal requirements gathering, modeling tools, the works. It was the SDLC/Six Sigma/ISO9000/vendor-certs-are-substitutes-for-degrees era of the late-90s/early-2000s. And it also didn't work. Often times, it's very easy to determine the functional requirements: "Process this billing statement", "Spit out that report." The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at the start that the users expect to interface with this system via email". To quote Mike Tyson, "everyone has a plan, until they get punched in the face." The point of Agile is to get punched in the face earlier and more frequently.
  - clarry 7y ago
    > The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at the start that the users expect to interface with this system via email". Those constraints sound like requirements: we require that only this ancient version of this database is used. We require that users can interface with this system via email. Different term, same thing. That's in the bucket with the kind of stuff that I'm advocating people should pay more attention to up-front. Gathering these requirements before you start designing anything is a big deal. If you failed to do so, then you failed to do a proper job at the part I called sitting down and figuring out the actual requirements.
    - moron4hire 7y ago
      A lot of places will never give you access to the people who can answer those questions and will expect you to start work right away and "quit wasting time" or they "put you on a Performance Improvement Plan"/fire you. The problem is not developers doing a bad job, it's management preventing them from doing good job.
      - clarry 7y ago
        Agreed, the industry isn't actually allowing engineers to engineer. https://news.ycombinator.com/item?id=22391047 https://news.ycombinator.com/item?id=22391047
- deleted 7y ago
  [deleted]

by bmn__ 7y ago

clarry 7y ago

I agree it's not easy, but instead of trying harder to become good at it, it seems like this industry in its proverbial baby shoes threw a tantrum and decided that it doesn't want to learn at all. So instead of pushing for more effort & skill for up-front planning and modelling of the requirements and design (and trying to employ modelling tools & formal methods), we're just like fuckit nah let's just implement something and see where that leads us. It doesn't help that so many of the up-front design failures were not examples of engineers screwing up but sales people selling shit and then having engineers cook it. We'll be stuck in baby shoes for a long time with this approach.

vinceguidry 7y ago
Companies are more than happy to churn through staff, losing millions in accumulated human knowledge, just to keep it out of the hands of employees. My company just shut down an entire office, they offered three out of four critical employees the opportunity to move to Atlanta. They didn’t want to move, opting to retire instead. Company just shrugged their shoulders rather than letting them work remote, gave them like a month to transfer knowledge and that’s that.
mewpmewp2 7y ago
Didn't we start by trying to plan ahead? There's a reason we have moved to agile. In software if you know what you are doing ahead of time you are not really innovating and you might as well be using an existing system. Since everything that is standardised you can just use as libraries. When building bridges, you can't just use a library that's .buildBridge(...parameters), even though similar things have been done thousands of times before. With code, if something is done enough times that you know how to plan for it, it is likely already a library. You can plan building a bridge since you have done that and have experience of it thousands times over.
- clarry 7y ago
  > Didn't we start by trying to plan ahead? There's a reason we have moved to agile. "Everything was waterfall and then came agile" is myth, but yes, it looks like it's fashionable to no longer try to plan ahead. I'm not convinced the reasons are good, and I'm not convinced the craft of planning ahead was ever perfected to the point that anyone could say it doesn't work. Scrum, XP, Agile all date back to the 90s when one server running PHP or Perl (with SQL injections) passed for software and others were still re-inventing basic data structures in C (and then gasp C++ with templates!) from first principles... The methodology, tooling, rigor, and collective experience in software development has taken leaps in the past two to three decades. Likewise, understanding systems and planning ahead has become so much easier. If only people took it seriously and spent as much effort on it as they spend on fad-of-the-year frameworks. People just stopped trying, and when I look in software projects now, there's hardly ever anything resembling a model of the software that you could use to test new ideas "on paper" to see how they fit the given problem and current application. People aren't even trying, just like they aren't even trying to achieve correctness: https://news.ycombinator.com/item?id=22224054 https://news.ycombinator.com/item?id=22224054 The less you try, the harder it will be. > In software if you know what you are doing ahead of time you are not really innovating and you might as well be using an existing system. I think the vast majority of software is boring and not even meant to be innovative and indeed would be best written using an existing system, but customizing these to the specific needs is just another can of worms. As with bridges, you can't just copy & paste an old bridge to a new location and use it as-it is, you need to design it given the locale and other constraints. It's still probably going to be yet another relatively boring bridge with no innovation. And indeed a lot of software work is all about using existing systems, but perhaps at a lower level than you posited. Customizing complete off-the-self packages does happen, but it's more common to glue something "new" (but not innovative) using existing frameworks, libraries, services and glue languages. You still need to design to do it right. But even here people seem to rush ass-first into whatever kit looks fashionable now.
moron4hire 7y ago
We tried all that. Formal requirements gathering, modeling tools, the works. It was the SDLC/Six Sigma/ISO9000/vendor-certs-are-substitutes-for-degrees era of the late-90s/early-2000s. And it also didn't work. Often times, it's very easy to determine the functional requirements: "Process this billing statement", "Spit out that report." The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at the start that the users expect to interface with this system via email". To quote Mike Tyson, "everyone has a plan, until they get punched in the face." The point of Agile is to get punched in the face earlier and more frequently.
- clarry 7y ago
  > The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at the start that the users expect to interface with this system via email". Those constraints sound like requirements: we require that only this ancient version of this database is used. We require that users can interface with this system via email. Different term, same thing. That's in the bucket with the kind of stuff that I'm advocating people should pay more attention to up-front. Gathering these requirements before you start designing anything is a big deal. If you failed to do so, then you failed to do a proper job at the part I called sitting down and figuring out the actual requirements.
  - moron4hire 7y ago
    A lot of places will never give you access to the people who can answer those questions and will expect you to start work right away and "quit wasting time" or they "put you on a Performance Improvement Plan"/fire you. The problem is not developers doing a bad job, it's management preventing them from doing good job.
    - clarry 7y ago
      Agreed, the industry isn't actually allowing engineers to engineer. https://news.ycombinator.com/item?id=22391047 https://news.ycombinator.com/item?id=22391047
deleted 7y ago
[deleted]