3 ms·

By the time someone writes the software, the business need has already changed. Software doesn't work. What? Since when did specs become immutable? Needs have

By the time someone writes the software, the business need has already changed. Software doesn't work. What? Since when did specs become immutable? Needs have changed? Patch the spec. It's faster than patching the software. From http://joelonsoftware.com/articles/fog0000000036.html http://joelonsoftware.com/articles/fog0000000036.html: "The most important function of a spec is to design the program. Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec -- describing how the program works in minute detail -- will force you to actually design the program." Sure, you'll still find out the design was wrong in some areas, and you'll have to change it. But at least you'll have a design to start from, as opposed to a hodgepodge of features carelessly tossed into the interface wherever the programmers found it most convenient to stick them, implemented in whatever way made the most sense to the programmers at the time.

mbell 14y ago
> Since when did specs become immutable? Needs have changed? Patch the spec. It's faster than patching the software. I don't understand how this can be faster. You patch the spec, then patch the software to match. I can't see how the spec could be patched faster. That is unless you patch the spec in isolation, prior to writing any code, which is a bigger mess. I've never, ever seen any group that can write a spec in isolation prior to writing code to demonstrate it, and have it come out well, its usually a disaster.
- LnxPrgr3 14y ago
  Did you read the link I posted? The idea is by having a spec, you're more likely to see where it needs to be patched upfront, before delivering poorly designed software to angry customers, so you spend less time re-working it later on. > I've never, ever seen any group that can write a spec in isolation prior to writing code to demonstrate it, and have it come out well, its usually a disaster. Can you elaborate? I'd be interested in hearing what they were building, who (in general terms) they were building it for, how they went about writing the specs, and what went wrong. My experience has been completely different, and I'm curious as to why that is. Edit: Of course you can't expect the customer to write the spec. Designing the software is your job. But that doesn't mean specs are broken; it just means asking your customers to write your specs for you is broken.
  - mbell 14y ago
    > My experience has been completely different, and I'm curious as to why that is. The majority of people who request 'software' haven't a clue what they want, they can't possibly describe it, you can't possibly write a spec for it. See years of research regarding waterfall vs agile development as a reference.
    - JabavuAdams 14y ago
      Interestingly, the waterfall model, as described by its inventor was iterative. See _Leprechauns of Software Development_
    - pionar 14y ago
      Seriously? Business software isn't about "what they want", it's about coming up with a solution to meet a business need. If the customer can't define what their business need is (the why of specs), then they have no reason to be in business. It's not the job of the spec writer to define the business need, it's to take an existing need (after clearly defining it through consultation with the customer) and then defining the parameters of the software - inputs, outputs, business rules. And it has absolutely nothing to do with agile vs. waterfall development. A well-written spec is crucial to ANY business software project. We do agile development at my company (a 25 year old enterprise software company) and will not begin work until we have a well-defined spec. I continually reject spec docs if they don't have enough info or if I have questions about an aspect of it. It's your job as a developer to help the spec writer see what problems may crop up and define a solution for them. I think you need to read Code Complete. It's absolutely mind-blowing the respect for specs you get after reading that book, even just chapter 3.
  - enjo 14y ago
    Big design up front! In my experience you never really understand a problem until you've implemented it. You can describe a problem and a solution in excruciating detail, but you'll never find every corner case. Sometimes (often?) those corner cases are really big deals. Better to prototype and iterate. Software should be the spec.

mbell 14y ago

> Since when did specs become immutable? Needs have changed? Patch the spec. It's faster than patching the software. I don't understand how this can be faster. You patch the spec, then patch the software to match. I can't see how the spec could be patched faster. That is unless you patch the spec in isolation, prior to writing any code, which is a bigger mess. I've never, ever seen any group that can write a spec in isolation prior to writing code to demonstrate it, and have it come out well, its usually a disaster.

LnxPrgr3 14y ago
Did you read the link I posted? The idea is by having a spec, you're more likely to see where it needs to be patched upfront, before delivering poorly designed software to angry customers, so you spend less time re-working it later on. > I've never, ever seen any group that can write a spec in isolation prior to writing code to demonstrate it, and have it come out well, its usually a disaster. Can you elaborate? I'd be interested in hearing what they were building, who (in general terms) they were building it for, how they went about writing the specs, and what went wrong. My experience has been completely different, and I'm curious as to why that is. Edit: Of course you can't expect the customer to write the spec. Designing the software is your job. But that doesn't mean specs are broken; it just means asking your customers to write your specs for you is broken.
- mbell 14y ago
  > My experience has been completely different, and I'm curious as to why that is. The majority of people who request 'software' haven't a clue what they want, they can't possibly describe it, you can't possibly write a spec for it. See years of research regarding waterfall vs agile development as a reference.
  - JabavuAdams 14y ago
    Interestingly, the waterfall model, as described by its inventor was iterative. See _Leprechauns of Software Development_
  - pionar 14y ago
    Seriously? Business software isn't about "what they want", it's about coming up with a solution to meet a business need. If the customer can't define what their business need is (the why of specs), then they have no reason to be in business. It's not the job of the spec writer to define the business need, it's to take an existing need (after clearly defining it through consultation with the customer) and then defining the parameters of the software - inputs, outputs, business rules. And it has absolutely nothing to do with agile vs. waterfall development. A well-written spec is crucial to ANY business software project. We do agile development at my company (a 25 year old enterprise software company) and will not begin work until we have a well-defined spec. I continually reject spec docs if they don't have enough info or if I have questions about an aspect of it. It's your job as a developer to help the spec writer see what problems may crop up and define a solution for them. I think you need to read Code Complete. It's absolutely mind-blowing the respect for specs you get after reading that book, even just chapter 3.
- enjo 14y ago
  Big design up front! In my experience you never really understand a problem until you've implemented it. You can describe a problem and a solution in excruciating detail, but you'll never find every corner case. Sometimes (often?) those corner cases are really big deals. Better to prototype and iterate. Software should be the spec.