4 ms·

That is an excellent question! I have been asking that myself all my professional life and I can now make an educated guess: lack of planning and mediocre spec

That is an excellent question! I have been asking that myself all my professional life and I can now make an educated guess: lack of planning and mediocre specification. I've read some comments here that I agree with; in a lot of cases the goals in dev are set to implement a solution to a problem either as fast as possible, or without a limited scope. "We need a software that can fly rockets" - Yeah, but where to? I studied computer science twice. Both times I have been taught to implement corner cases instead of working on clearly defined projects with scope and specification. "Write a small program that does X" yeah, but the solution space is unlimited, then, maybe? Can you elaborate? Put a scope on it? I mean, can do, may I order compute time on the campus super-computer? Crap software was there ever since, and it got worse ever since.

pjc50 4y ago
> instead of working on clearly defined projects with scope and specification Yes, it's much easier once you get to that point. Getting there is the real work. Wrangling clarity into requirements from messy humans isn't amenable to all the nice formal methods, but it's a very critical part of the work.
- learningstud 4y ago
  Could it be that formal methods are exactly the solution to "wrangling clarity into requirements from messy humans"? Business people and programmers could work closely together to incrementally build a list of formal requirements with the help of proof assistants. So that both parties can know clearly what are known to be ambiguous and what can be implemented immediately at every stage of discussion. Update the formal list of requirements whenever anyone has a breakthrough. Investigate into possible inconsistency early on with the help of proof assistants. Enforce project-wide constraints for every update to the list of requirements. Cooperate to make more and more informal stuff formal to reduce misunderstanding. Formal methods can help with exploration and cooperation.
  - dschuetz 4y ago
    "Business people" and programmers are inherently incompatible, because there is a clash of interests. What you need in dev team is a programmer who balances possible solutions against requirements, and only their decision counts, and guides the other programmers. "Heya, our software is gonna be great if we add this nifty feature I wrote last week" then the deciding has got to say "save that for the next major release, let's get the requirements working bug-free and testable first!"

pjc50 4y ago

> instead of working on clearly defined projects with scope and specification Yes, it's much easier once you get to that point. Getting there is the real work. Wrangling clarity into requirements from messy humans isn't amenable to all the nice formal methods, but it's a very critical part of the work.

learningstud 4y ago
Could it be that formal methods are exactly the solution to "wrangling clarity into requirements from messy humans"? Business people and programmers could work closely together to incrementally build a list of formal requirements with the help of proof assistants. So that both parties can know clearly what are known to be ambiguous and what can be implemented immediately at every stage of discussion. Update the formal list of requirements whenever anyone has a breakthrough. Investigate into possible inconsistency early on with the help of proof assistants. Enforce project-wide constraints for every update to the list of requirements. Cooperate to make more and more informal stuff formal to reduce misunderstanding. Formal methods can help with exploration and cooperation.
- dschuetz 4y ago
  "Business people" and programmers are inherently incompatible, because there is a clash of interests. What you need in dev team is a programmer who balances possible solutions against requirements, and only their decision counts, and guides the other programmers. "Heya, our software is gonna be great if we add this nifty feature I wrote last week" then the deciding has got to say "save that for the next major release, let's get the requirements working bug-free and testable first!"