3 ms·

I find it interesting that I've gotten downvoted for this comment. Building an MVP and then iterating seems to be the modus operandi of the HN community. Buil

by mbell 14y ago

I find it interesting that I've gotten downvoted for this comment. Building an MVP and then iterating seems to be the modus operandi of the HN community. Building a detailed spec is the anti-thesis of this movement. How does this correlate?

blago 14y ago
The world of software development is a lot bigger than HN.
munger 14y ago
I didn't down vote you, but my experience with writing specs has been positive. Maybe you are talking about running your own start-up where it might not be successful yet? And you're trying to find your market fit? Then sure, maybe just writing new code and changing the product on a whim is what is best without writing up a spec. Now consider a software consultancy with enterprise customers. The enterprise usually wants time and cost estimates, which usually means agreeing on precisely what you will be delivering in advance. You WANT to write a spec, to prevent scope creep and limit your liability, and they want you to tell them how long and how much (and a spec helps estimate those things). It's win-win. Most enterprise customers can't wrap their CFO's head around true agile with iterations and open-ended times and costs. They want as much of a guarantee as you can give them for what/how long/how much. Not saying one way is better or worse - but maybe it's a case of the right tool for the job?
Tyrannosaurs 14y ago
Because the fact one model is working for the HN community doesn't mean that other models don't work but you made a very definite and sweeping statement. We use specs because our customers tend to be somewhat staid and want certainty and predictability. By keeping chunks of functionality relatively compact (say 3 person months typically, then developed over a period of maybe 6 weeks) writing an accurate and useful spec is absolutely doable. Doing that we'll usually be 95% (or more) right and any adjustments can be made in a small release a couple of weeks later. The approach has elements of agile and iteration in it (small releases, the UAT and fix process is basically a short agile sprint) but specs are absolutely a working part of it. Could we do it another way if our clients would accept it? Sure? But do the specs work in the current process? Yes they do.
mcguire 14y ago
"Building an MVP and then iterating..." If you get your feedback on iterations in writing, you will probably get fewer self-contradictory or illegal, immoral, unethical, or unimplementable demands.

by mbell 14y ago

blago 14y ago

The world of software development is a lot bigger than HN.

munger 14y ago

I didn't down vote you, but my experience with writing specs has been positive. Maybe you are talking about running your own start-up where it might not be successful yet? And you're trying to find your market fit? Then sure, maybe just writing new code and changing the product on a whim is what is best without writing up a spec. Now consider a software consultancy with enterprise customers. The enterprise usually wants time and cost estimates, which usually means agreeing on precisely what you will be delivering in advance. You WANT to write a spec, to prevent scope creep and limit your liability, and they want you to tell them how long and how much (and a spec helps estimate those things). It's win-win. Most enterprise customers can't wrap their CFO's head around true agile with iterations and open-ended times and costs. They want as much of a guarantee as you can give them for what/how long/how much. Not saying one way is better or worse - but maybe it's a case of the right tool for the job?

Tyrannosaurs 14y ago

Because the fact one model is working for the HN community doesn't mean that other models don't work but you made a very definite and sweeping statement. We use specs because our customers tend to be somewhat staid and want certainty and predictability. By keeping chunks of functionality relatively compact (say 3 person months typically, then developed over a period of maybe 6 weeks) writing an accurate and useful spec is absolutely doable. Doing that we'll usually be 95% (or more) right and any adjustments can be made in a small release a couple of weeks later. The approach has elements of agile and iteration in it (small releases, the UAT and fix process is basically a short agile sprint) but specs are absolutely a working part of it. Could we do it another way if our clients would accept it? Sure? But do the specs work in the current process? Yes they do.

mcguire 14y ago

"Building an MVP and then iterating..." If you get your feedback on iterations in writing, you will probably get fewer self-contradictory or illegal, immoral, unethical, or unimplementable demands.