4 ms·

These lines sound like a recipe for scope/feature creep and never ending development process. >Never do requirement analysis. Never write technical requirement

by retox 10y ago

These lines sound like a recipe for scope/feature creep and never ending development process. >Never do requirement analysis. Never write technical requirements or functional ones. If you do, you have already failed. In that case, how do you know when the software is finished and your contract has been fulfilled? >Creative solutions are often holistic in nature, driven by first-hand experience, discussion, interaction and... thinking. If you want a developer to write a great piece of code, let him or her scratch the itch you're trying to scratch. So, you do all your thinking, without capturing anything, and then the software is finished when the developer is bored?

gonzo41 10y ago
Theres 'building castle from our minds' developing and then there's 'get shit done' developing. I'm kind of sick of so many devs fighting to try and outsmart each other. I'm looking at legacy code basses where people wanted to have a go at a technology and it just became an unmanageable abortion because they move on, support picks up the gig and then rot. Now I'm learning obscure technologies not in use by the majority of the bell curve because someone had a thought bubble. -- end rant. I'm all for the middle ground. Money flows to those who deliver.
UK-AL 10y ago
Tbh I know what he is saying. Software that is speced up by BA's and driven by their requirements tends to end up being really bad software. The best software is built up over time as demand arises for those features. Create the feature requests as they are required and implement the requests. I think one of the major causes of why this type of thinking ends up building bad software is that BAs include literally every corner case they can think of. Ends up being extremely complicated right from the start. Then they miss other requirements. If you build by evolving software from a simple beginning just to scratch an itch, you learn the true requirements from experience. Learning about the optimal architecture from experience as they go. Hard to do when your working off a software dev contract. Fairly easy to do if your building a product. It's cathedral vs bazaar.
- vonmoltke 10y ago
  Sounds like the flaw is having business analysts do the requirements analysis instead of systems engineers. It also assumes you are creating a standalone application and not a piece of a larger system.
wjd2030 10y ago
These may make sense in a Utopian existence where profit means nothing. However in the real world, projects are driven by requirements, and the developer that can fill these requirements the fastest is the developer that will prosper the greatest.
agentultra 10y ago
Right? Never mind that thoughtfulness of design is a requirement to understanding complex distributed systems. And before we go off saying that few developers need to know how to program distributed systems consider that even a modern processor is a tiny distributed system. This idea that genius will spout forth from the hands of the programmer in the spur of the moment is hogwash. If you believe this then let's make a wager. We'll pick a simple, standard algorithm. I'll give you the requirements, you implement it. I'll model your solution and run it in a model checker. I bet you that the checker will find an error in your implementation. Simple, right? A colleague of mine did this to his students. They had to implement binary search. The majority of their solutions had bugs. These weren't under-grads. Programming is hard because thinking is hard and we deserve the best tools we can find to help us think clearly and precisely. In the real-world we can always just add a fudge-factor to make up for our uncertainty while computers are infuriatingly discrete systems. This flow of "thinking in code," is simple-minded ignorance. Think in code all you want. You won't be able to solve the hard problems that way. You'll just write sloppy code. ... </rant>
qwertyuiop924 10y ago
you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.
- vonmoltke 10y ago
  There are domains wherein the software is inherently this complex and requirements analysis is unavoidable. This is particularly true when decomposing one large system into small systems. Someone needs to be the systems engineer that determines how the pieces couple together and how overall system functionality is divided into the pieces. Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.
  - qwertyuiop924 10y ago
    Huh. Fair enough. I wasn't really thinking quite like that, but that is true
- king_magic 10y ago
  Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.
  - qwertyuiop924 10y ago
    I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
    - king_magic 10y ago
      And I disagree right back at you :) All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements. It's not "certainly less complex". The total complexity of the system is still the same.
lkrubner 10y ago
Somewhat related, "The Agile process of software development is often perverted by sick politics" http://www.smashcompany.com/business/the-agile-process-of-software-development-is-often-perverted-by-sick-politics http://www.smashcompany.com/business/the-agile-process-of-so...
hinkley 10y ago
I've yet to meet a requirements document that was good enough for both parties to agree that the contract had been fulfilled. It's almost always come down to browbeating or going unpaid. What that requirements document is is a license to withhold payment until the contract obligations are met, no matter how ruinous those obligations are because of inattention to detail and the customer's complete lack of ability to state clearly what they want. I think one of the biggest things us developers misunderstand about Agile is that it involves a contract that says you pay me every month for a month's worth of work. If 8 months into a 12 month project, the customer decides they don't like us, we've already cashed 8 checks and are free to pursue other projects. At worst I have 8 months of money and I have to scramble to find new projects for my team. With the typical up front big design the customer just refuses to write a check until you've fulfilled their handwavy interpretation of the requirements, which mean whatever they want them to mean this week. We could easily be on month 20 still hoping to get our second check for 6 months' of pay. Essentially we're chewing people up and bankrupting the company in the process. It's a sucker's bet. Lately I've gotten even more cynical. My new thesis is that companies that know how to ask for what they need and can break problems down into reasonable and measurable parts don't usually hire out work. They have all the necessary skills to just open job reqs and get their code written. The people who hire contractors seem to almost universally do it because they don't have the faintest clue how to spec and write a piece of software. Including doing the requirements. Especially the requirements. Be sure to quote them a rate that represents hazard pay, because there's gonna be drama.

by retox 10y ago

gonzo41 10y ago

Theres 'building castle from our minds' developing and then there's 'get shit done' developing. I'm kind of sick of so many devs fighting to try and outsmart each other. I'm looking at legacy code basses where people wanted to have a go at a technology and it just became an unmanageable abortion because they move on, support picks up the gig and then rot. Now I'm learning obscure technologies not in use by the majority of the bell curve because someone had a thought bubble. -- end rant. I'm all for the middle ground. Money flows to those who deliver.

UK-AL 10y ago

Tbh I know what he is saying. Software that is speced up by BA's and driven by their requirements tends to end up being really bad software. The best software is built up over time as demand arises for those features. Create the feature requests as they are required and implement the requests. I think one of the major causes of why this type of thinking ends up building bad software is that BAs include literally every corner case they can think of. Ends up being extremely complicated right from the start. Then they miss other requirements. If you build by evolving software from a simple beginning just to scratch an itch, you learn the true requirements from experience. Learning about the optimal architecture from experience as they go. Hard to do when your working off a software dev contract. Fairly easy to do if your building a product. It's cathedral vs bazaar.

vonmoltke 10y ago
Sounds like the flaw is having business analysts do the requirements analysis instead of systems engineers. It also assumes you are creating a standalone application and not a piece of a larger system.

wjd2030 10y ago

These may make sense in a Utopian existence where profit means nothing. However in the real world, projects are driven by requirements, and the developer that can fill these requirements the fastest is the developer that will prosper the greatest.

agentultra 10y ago

Right? Never mind that thoughtfulness of design is a requirement to understanding complex distributed systems. And before we go off saying that few developers need to know how to program distributed systems consider that even a modern processor is a tiny distributed system. This idea that genius will spout forth from the hands of the programmer in the spur of the moment is hogwash. If you believe this then let's make a wager. We'll pick a simple, standard algorithm. I'll give you the requirements, you implement it. I'll model your solution and run it in a model checker. I bet you that the checker will find an error in your implementation. Simple, right? A colleague of mine did this to his students. They had to implement binary search. The majority of their solutions had bugs. These weren't under-grads. Programming is hard because thinking is hard and we deserve the best tools we can find to help us think clearly and precisely. In the real-world we can always just add a fudge-factor to make up for our uncertainty while computers are infuriatingly discrete systems. This flow of "thinking in code," is simple-minded ignorance. Think in code all you want. You won't be able to solve the hard problems that way. You'll just write sloppy code. ... </rant>

qwertyuiop924 10y ago

you missed the point: The point is, if the requirements for a piece of code are so complex that you NEED to write a requirement analysis, that you NEED to do anything other than plan out your code, and write it, than your software is already too complicated. You need to narrow the scope. Lots of small systems is better than one large system.

vonmoltke 10y ago
There are domains wherein the software is inherently this complex and requirements analysis is unavoidable. This is particularly true when decomposing one large system into small systems. Someone needs to be the systems engineer that determines how the pieces couple together and how overall system functionality is divided into the pieces. Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.
- qwertyuiop924 10y ago
  Huh. Fair enough. I wasn't really thinking quite like that, but that is true
king_magic 10y ago
Yeah, sorry, but real life software doesn't work that way. Real life software is often inherently complex.
- qwertyuiop924 10y ago
  I disagree. Complexity can arise through interactions between simple pieces of software. Given, planning that out may be complex, but certainly less complex than writing it all in one go.
  - king_magic 10y ago
    And I disagree right back at you :) All you're doing is shifting complexity around. Don't want one big piece of complex software? Fine. Break it up - now you have a bunch of simple pieces of software that all need to work together in a complex manner. You still need to plan for how all that works, and that often requires complex requirements. It's not "certainly less complex". The total complexity of the system is still the same.

lkrubner 10y ago

Somewhat related, "The Agile process of software development is often perverted by sick politics" http://www.smashcompany.com/business/the-agile-process-of-software-development-is-often-perverted-by-sick-politics http://www.smashcompany.com/business/the-agile-process-of-so...

hinkley 10y ago

I've yet to meet a requirements document that was good enough for both parties to agree that the contract had been fulfilled. It's almost always come down to browbeating or going unpaid. What that requirements document is is a license to withhold payment until the contract obligations are met, no matter how ruinous those obligations are because of inattention to detail and the customer's complete lack of ability to state clearly what they want. I think one of the biggest things us developers misunderstand about Agile is that it involves a contract that says you pay me every month for a month's worth of work. If 8 months into a 12 month project, the customer decides they don't like us, we've already cashed 8 checks and are free to pursue other projects. At worst I have 8 months of money and I have to scramble to find new projects for my team. With the typical up front big design the customer just refuses to write a check until you've fulfilled their handwavy interpretation of the requirements, which mean whatever they want them to mean this week. We could easily be on month 20 still hoping to get our second check for 6 months' of pay. Essentially we're chewing people up and bankrupting the company in the process. It's a sucker's bet. Lately I've gotten even more cynical. My new thesis is that companies that know how to ask for what they need and can break problems down into reasonable and measurable parts don't usually hire out work. They have all the necessary skills to just open job reqs and get their code written. The people who hire contractors seem to almost universally do it because they don't have the faintest clue how to spec and write a piece of software. Including doing the requirements. Especially the requirements. Be sure to quote them a rate that represents hazard pay, because there's gonna be drama.