4 ms·

What you're saying is completely right after you realize that the problem with business software is not the software side, it is the illogical requirements of b

What you're saying is completely right after you realize that the problem with business software is not the software side, it is the illogical requirements of businesses. The issue is that different parts of the businesses throw requirements that are contradictory and generate unmaintainable systems in the long run. Thus the need to constantly rewrite and patch. In an "enterprise" setting, you don't want a solution oriented language, you want a language that can be twisted to produce whatever the business wants in a short period of time.

bitwize 2y ago
The problem with business requirements is that there are no systems analysts anymore; that work has largely been given to programmers. A systems analyst could determine what information each part of the business needs and what information it can provide to whom. With that information in hand, designing an information system becomes a relatively straightforward process; programming it even more so. The way we do things today is basically guesswork. Which suits programmers just fine, as it lets them write a lot of code. But that's not the best of all possible worlds, only the default world.
- coliveira 2y ago
  Everything that involves planning and long term thinking has been eliminated from modern businesses, under the guise of "fast iteration", "just-in-time", or whatever new name they find. It's not a software-only phenomenon.
- exe34 2y ago
  the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users, and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work.
  - bitwize 2y ago
    > the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users This is really only an issue if you appoint programmers to serve as systems analysts. Sadly, this is all too common among businesses today. Remember, programmers are detailists who must speak the language of the computer, and do not see the big picture, only one small part of a much bigger puzzle. A good systems analyst is a generalist who understands the business and can empathize with the users. They have strong communication skills, and can take a big-picture perspective and articulate their perspective and solutions clearly to management. They most certainly would not dismiss user requests and complaints as "incoherent ramblings". Programming and systems analysis are separate professions that require vastly different personality types, with the consequence that programmers make very poor systems analysts.
    - exe34 2y ago
      > and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work. There's a reason we don't have them anymore.
      - bitwize 2y ago
        You're putting the cart before the horse. Again, gathering requirements is a time-consuming and confusing process, making the software late and often wrong, because most companies assign programmers to the systems analysis process, not people skilled in actual systems analysis. A good systems analyst has the empathy and high-level insight it takes to understand the existing business systems and the true needs of the users, and design a new system to better meet those needs -- traits sorely lacking in programmers. Note that a business system is not the same as software. It incorporates all of the procedures, whether performed by humans or machine, necessary for business operations. As a consequence, we tend to declare that nothing can be done about gathering requirements and implement "Agile" methodologies, which are nothing more than institutionalized guesswork: in the words of Milt Bryce, "do a superficial feasibility study, do some quick and dirty systems design, spend a lot of time in programming, install prematurely so you can irritate the users sooner, and then keep working on it till you get something accomplished." And the software is still late and wrong!

bitwize 2y ago

The problem with business requirements is that there are no systems analysts anymore; that work has largely been given to programmers. A systems analyst could determine what information each part of the business needs and what information it can provide to whom. With that information in hand, designing an information system becomes a relatively straightforward process; programming it even more so. The way we do things today is basically guesswork. Which suits programmers just fine, as it lets them write a lot of code. But that's not the best of all possible worlds, only the default world.

coliveira 2y ago
Everything that involves planning and long term thinking has been eliminated from modern businesses, under the guise of "fast iteration", "just-in-time", or whatever new name they find. It's not a software-only phenomenon.
exe34 2y ago
the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users, and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work.
- bitwize 2y ago
  > the problem is that the requirements take 6 months to elucidate from the incoherent ramblings of the users This is really only an issue if you appoint programmers to serve as systems analysts. Sadly, this is all too common among businesses today. Remember, programmers are detailists who must speak the language of the computer, and do not see the big picture, only one small part of a much bigger puzzle. A good systems analyst is a generalist who understands the business and can empathize with the users. They have strong communication skills, and can take a big-picture perspective and articulate their perspective and solutions clearly to management. They most certainly would not dismiss user requests and complaints as "incoherent ramblings". Programming and systems analysis are separate professions that require vastly different personality types, with the consequence that programmers make very poor systems analysts.
  - exe34 2y ago
    > and by the time you've figured it out, the business has moved on and has new and incompatible requirements. so your software is late, doesn't meet the requirements and doesn't even work. There's a reason we don't have them anymore.
    - bitwize 2y ago
      You're putting the cart before the horse. Again, gathering requirements is a time-consuming and confusing process, making the software late and often wrong, because most companies assign programmers to the systems analysis process, not people skilled in actual systems analysis. A good systems analyst has the empathy and high-level insight it takes to understand the existing business systems and the true needs of the users, and design a new system to better meet those needs -- traits sorely lacking in programmers. Note that a business system is not the same as software. It incorporates all of the procedures, whether performed by humans or machine, necessary for business operations. As a consequence, we tend to declare that nothing can be done about gathering requirements and implement "Agile" methodologies, which are nothing more than institutionalized guesswork: in the words of Milt Bryce, "do a superficial feasibility study, do some quick and dirty systems design, spend a lot of time in programming, install prematurely so you can irritate the users sooner, and then keep working on it till you get something accomplished." And the software is still late and wrong!