Hacker News new | past | comments | ask | show | jobs | submit login

In a book like this, I'd like to see cost estimation mentioned earlier than Chapter 8. I'd argue that in nearly all software development projects (particularly the ones where this sort of book applies) the cost of implementation is one of the key factors in evaluating requirements. If you put together your requirements without considering their cost, you end up with a project that's too expensive to build, and you want to know that during the Requirements Gathering phase, not later on during construction. Even Agile projects need to start out with a rough idea of what's being built and a rough idea of what it'll cost to build it. Otherwise how does the person funding the project decide whether or not to approve it?

Of course, as we all know providing estimates during the requirements phase is very difficult, especially if they're treated as hard commitments rather than rough ballparks. Chapter 2 mentions that getting requirements wrong is a key factor in causing software projects to fail; I'd say that the reason for that is usually because of the implementation costs of the known requirements that were estimated inaccurately or not at all, and the implementation costs of requirements that aren't discovered until later. It always comes down to cost; I think it's relatively rare for a software project to fail because a requirement turned out to be impossible to implement. (Unless it involves AI. You always have to watch for people trying to sneak in an AI requirement.)

At my uni our Software Engineering I (CS301 or maybe it was II[CS302]) class was entirely based on requirements gathering and estimation.

It was a real eye opener for me- I'd been writing code in many languages since I was 10, but this was my first glimpse at "that other stuff" that takes up the majority of one's day.

All in all, I feel like it prepared me for what I would face in the real world. We had to do stakeholder interviews where the professor or a TA played the role of unforthcoming/neurotic stakeholder, were introduced to various general document types like stakeholder analysis, cost/benefit analysis, requirements overviews, etc. and the last 1/3 was pretty much applying all the interviews and data to an estimation process. We also did a greenfield project, an additional functionality project, and a system replacement project to work through the pitfalls of each.

I also think it was the first time I read The Mythical Man Month and Waltzing with Bears.

The two things, by far, that stick out about recent college grads (or really, new developers in general) are the inability to estimate and gather requirements and a complete lack of knowledge around source control.

GitHub and a lot of projects that are based around checking project source out has made a lot of Junior devs more familiar with at least the idea of source control, but very little prepares them for the flailing and hand wringing that comes with estimation.

Great high-level feedback, thanks. I'll add a cost/estimates component to Requirements.

I've added a stub section on the subject that I will expand as I learn more: http://mixmastamyk.bitbucket.org/pro_soft_dev/sdlc_2_req.htm...

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact