3 ms·

> It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. That's why you have a Proje

by ssmoot 12y ago

> It is unrealistic to expect a non-technical stake holder to deeply and accurately describe anything but the most trivial feature. That's why you have a Project Manager / Business Analyst / Whatever Title You Prefer. Few would consider going out and hiring their own construction crew to build their new house, managing materials deliveries, blockers, scheduling, head-count, etc. That's what a General Contractor is for. But in software, both (some) business people and (some) developers think they can get away with attempting to go down a well-travelled path (by others) and do it all themselves. Without that experience and expertise it's more likely than not IME that you'll spend more than you have to, and since you aren't a scheduling wizard and are trying to keep all this stuff in your head, you'll have numerous "stop work"s, conflicts, change-orders for half-baked designs, etc. If you're building anything beyond the trivial, and you'd like to have a reasonable ball-park for what it's going to cost and how long it's going to take, make sure you're talking to the GC and not the plumber. And run far away from any business that tells you they cut out overhead by removing the GC. I saw a slide not too long ago depicting a development process. It went something like: Skateboard -> Bicycle -> Scooter -> Car -> Truck. If I'm the one writing the cheques, I'd be pretty pissed that I paid for four vehicles I didn't need before I got the one I did. Especially when it could have all been easily avoided by asking the right questions. Agile can favor items on the left over items on the right. That doesn't mean you don't do the items on the right. It doesn't mean you start without a contract. It doesn't mean you don't plan. It doesn't mean you don't document requirements. There's nothing Agile about having a chat between A and B, sitting at a keyboard, and spending money. That's just cowboy coding. And when it inevitably goes south, best of luck getting the stockholder to fall on their sword for you.

dansingerman 12y ago
> There's nothing Agile about having a chat between A and B, sitting at a keyboard, and spending money. That's just cowboy coding Nowhere did I suggest having the conversation was the entire process. I am merely rejecting the notion that a story is a spec. I believe there should be no concept of spec at all. There should be a story, a conversation, and then acceptance criteria (which should ideally be defined in code, not a document)
- ssmoot 12y ago
  So you would write functional acceptance tests, and the only thing written down is a Story. If all goes well, maybe you have a happy client at the end of that. If they're OK with costs and time being potentially an order-of-magnitude off. Most people outside of the software world aren't. Most people outside of the software world use specs. I feel like if there were a better, more reliable way to build something, anything, it would be common. But wether it's a car, a house, a boat, a bridge, a road, a piece of furniture or a motion film, that's not the way it works generally. If you want repeat business anyways. I feel like resounding success without specs is the exception. At least it's always been that way in my career. The less planning effort, the less success. The correlation is so strong IME that it's basically like saying fire is hot. As someone whose dealt with independent contractors for house work, it really sucks for a client to not know the what, for how much and when. I've never met a client that objected to nailing those down (within reason) before I started sending over invoices for Developer hours.
  - dansingerman 12y ago
    In my experience people buying software value working software that meets their business requirements within the agreed budget over anything else. In twenty years I have never known a written specification help achieve that, and it has often hindered it. I guess your experience differs, but I focus on delivering software my clients love, and so far that has never failed to work.

by ssmoot 12y ago

dansingerman 12y ago

> There's nothing Agile about having a chat between A and B, sitting at a keyboard, and spending money. That's just cowboy coding Nowhere did I suggest having the conversation was the entire process. I am merely rejecting the notion that a story is a spec. I believe there should be no concept of spec at all. There should be a story, a conversation, and then acceptance criteria (which should ideally be defined in code, not a document)

ssmoot 12y ago
So you would write functional acceptance tests, and the only thing written down is a Story. If all goes well, maybe you have a happy client at the end of that. If they're OK with costs and time being potentially an order-of-magnitude off. Most people outside of the software world aren't. Most people outside of the software world use specs. I feel like if there were a better, more reliable way to build something, anything, it would be common. But wether it's a car, a house, a boat, a bridge, a road, a piece of furniture or a motion film, that's not the way it works generally. If you want repeat business anyways. I feel like resounding success without specs is the exception. At least it's always been that way in my career. The less planning effort, the less success. The correlation is so strong IME that it's basically like saying fire is hot. As someone whose dealt with independent contractors for house work, it really sucks for a client to not know the what, for how much and when. I've never met a client that objected to nailing those down (within reason) before I started sending over invoices for Developer hours.
- dansingerman 12y ago
  In my experience people buying software value working software that meets their business requirements within the agreed budget over anything else. In twenty years I have never known a written specification help achieve that, and it has often hindered it. I guess your experience differs, but I focus on delivering software my clients love, and so far that has never failed to work.