Hacker News Reader

Comment by ExpiredLink | Hacker News Reader

> I think in my ~20year career, I've had only 3 projects that were specified well enough up front that we just "built it according to the plans" and had a satisfied customer at the end. Overwhelmingy, some (or most) of the design gets "made up as we go along". Even on projects with several small forests worth of up-front documentation, there's almost always large areas of vagueness or outright contradictory requirements, which need decision making on the developers part halfway into the job.

So the underlying development method, nowadays denounced as 'waterfall', wasn't sufficient? I am not an Agile zealot but change and 'knowing better' needs to be embraced during the development process and not ruled out.

View on HN

Right, I've worked on many projects where it wasn't really possible to gather all requirements up front. This is hugely frustrating to everyone involved but the fact remains that until you have at the very least a working prototype you will often not be able to generate a final requirements document.

On the other hand when requirements are nailed from the very start, the development proccess has been swift, well executed and largely bug free.

While developers love discussing the pros and cons of different languages, libraries and frameworks I often think that more work should be put into developing ways of better capturing requirements, as this has such a huge effect on the amount of time a project will take.

Agreed. My experience is that there is way too much emphasis on languages, libraries, and frameworks. Nobody really talks about the methodologies of building software. For any given day on HN, how many articles are about how such-and-such extension for this-and-that language is the best thing since the great pyramids and how many are about how code review can help reduce bugs? Or how to more effectively gather requirements? Or anything about comprehensive testing practices (unit tests are just a small part of effective testing.)

Right on.

There is also a gap in discussion of software architecture. Everyone seems happy to use whatever their framework forces them into, or add more machinery to make up for it. Concepts like coupling and cohesion don't get much airtime, particularly with the prevalence of dynamic languages.

I think that's largely because languages, libraries, and frameworks are advancing, and methodologies are not. Better methodologies are becoming more widespread, but there's very little that's being invented that's actually new.

And that is what actually differentiates software engineering from other engineering disciplines. You cant't simply embrace change when building a house or you'd have to tear it down multiple times during building...

I've worked in construction, and that's actually not the case at all. What happens is very similar to what happens in software development: someone realizes that the spec is borked; the subcontractor and general contractor get together to look it over, and come up with a kludge that fixes the problem as easily as possible.

If the change is at the customer's request, they get charged a nice premium and the necessary changes are made. At the end of the day, everyone still gets paid regardless of how often the customer changes their mind.

This, then, is perhaps what the trades do better than us: they're very upfront with the customer about added costs. "Yes, we can make your bathtub a jacuzzi. It'll cost you $2500 more and the job will take a couple days more. Do you want to go ahead with your change?" Because there is a clear and complete plan that the customer signs off on before construction begins, it's very easy to show them what a change in requirements entails.

Everyone can envision what knocking a wall down means, and can see it will cost money and time. Many decide, upon reflection, that they really don't care enough to pay that price. Others go nuts and end up with expensive projects that take forever. Either way, the contractors get paid.

Use Agile for R&D, user Waterfall for D only.

E.g. use Agile and smart guys with good knowledge of application domain for first version, then drop it and rewrite from scratch using Waterfall and outsource professionals.

It is ok if you don't change anything (or nothing significant) between version 1 and 2. But then, why would you rewrite from scratch ? In any case, if you use a different team to rewrite your application, you just lost the biggest value of the previous team: experience solving that problem the first time. No amount of documentation can really make up for the difference . The source (with doc) of a software is a compiled version of business/technical knowledge of the team that developed it and not really that good as a guide to the next team.

> But then, why would you rewrite from scratch?

Why not? Professionals knowns their tools much better, so they will made better choices in every aspect of project. If you place restrictions on their tools, they will work less efficient, unless you are already professional developer.

> The source (with doc) of a software is a compiled version of business/technical knowledge of the team that developed it and not really that good as a guide to the next team.

Of course. They will ask questions, so somebody from first team should respond to them.

Use agile for R&D, apt-get install for D only.

Reply on news.ycombinator.com