Hacker News Reader

Comment by RNeff | Hacker News Reader

This is the best book on software engineering and project management.

1. Need standards for process, coding style, change control, documentation. Must be easy to move people between projects without massive retraining. Implies use only one programming language.

2. Change control is essential.

3. Some projects cannot be completed faster: Nine women will not produce a baby in one month.

4. Forced schedules will impact quality.

5. There is No Silver Bullet. There is implicit difficulty that cannot be changed by tools, process, training.

Just read the book!

View on HN

I'd also add 1A) when hiring, you must consider the amount of time to train a person and that each additional person adds more work for communication. It explains why adding more people to a project that is already late, will actually make it later

This is probably the best short summary I've seen on The Mythical Man-Month. Kudos! Do you have any other books of a similar vein to recommend?

I am reading the book :)

I just wanted to know, given that someone outside the software engineering has read the book or that someone inside the software engineering, can shed some light on - "the techniques proven and routine in other engineering discipline are considered radical innovations in software engineering".

Remember that the book was written in the 80s, so some things have been adopted since then. One example is version control, which wasn't standard until the mid-2000s. A different example is that most other engineering disciplines require formal diagrams to be created and approved (houses require blueprints, and those typically need to be filed with the local city government) whereas most software companies often wing it with a quick description of what to build. FYI, in Sweden there's actually a museum dedicated to a ship that sank 1000 yards on its maiden voyage during a time when shipbuilders didn't use diagrams but were overseen by a master architect

A software shipped with life-supporting medical equipments, for example, should not have the missing spec problem. Or, I assume so.

You’ve heard about the Therac-25, right?

That one killed lots of people.

Apart from spec-ing the projects before kickoff, do you have any insights about how the engineering teams, outside the SE domain, communicate and co-ordinate?

> FYI, in Sweden there's actually a museum dedicated to a ship that sank 1000 yards on its maiden voyage during a time when shipbuilders didn't use diagrams but were overseen by a master architect

In case anyone got curious, that's https://en.wikipedia.org/wiki/Vasa_(ship)

That is a great story on so many levels (ha). Scope creep, letting non-technical decision override technical ones.

”Remember that the book was written in the 80s”

Nitpick: 1975 (had to look it up to check whether my memory “it must be older” was right)

> One example is version control, which wasn't standard until the mid-2000s.

Distributed version control wasn't standard until Git and Hg (2005). Version control has been around for decades. CVS (1986/1990) was popular in the open-source communities, while ClearCase (1992) and others were more common in industry.

It took a while for Git to shake out as the standard version control, but version control in general has been standard industry practice for a long time. Let's give credit where credit is due. The need to track changes to software is not some recent idea.

Incidentally, I happened to spend a few hours at the Vasa Museum in Stockholm earlier this year.

It's a glorious 17th-century wooden ship. In 1628, it sank like a stone, after travelling just one KM on its maiden journey in Stockholm waters; 30 out of the 145 people died. And Vasa stayed under water for 333 years. Then it was recovered in 1961—the only (?) 17th century ship to be preserved. Its ongoing preservation itself a singularly unique scientific project.

It's a spectacular ship, with hundreds of impressive wooden sculptures, carvings and other abilities (displaying the might of the king). 95% of the ship is in remarkably original condition—because, luckily for the ship, the Baltic Sea is not conducive to shipworms.

If you are around the area, definitely take the time visit it. (The small city island where it's located, Djurgården, also has other serene places.)

</end digression>

Not having the read the book, what is #4 about? Are deadlines not a necessary thing? Don’t most SW teams use sprints to push out features on a regular basis?

#4 states that there's a tradeoff. If you are working on a project, and you can tell that as designed the project will be finished a month late, there are two options: 1) move the deadline or 2) Reduce quality/features. The example used in the book is a cook making omelettes. If it takes 5 minutes to make an omelette and the cook promises it in 4, at minute 3, the cook can either tell you it's actually going to take 5 minutes or the cook can turn up the heat and make a crappy omelette. In SW terms, SW teams are working on a project that is estimated at 8 sprints. At week 4, they're currently on track to finish it in 10 sprints. The SW teams can either remove features, reduce quality (maybe they skip writing tests or code reviews or decide to use a "hacky" solution instead of the "right" solution) or move the deadline.

I didn't read the book but I tend to disagree with 1.

- I've seen a lot of well standardized projects fail. And a lot of disorganized projects succeed. Failure with standardized projects are often attributed to "not followed the standard properly", but if following the standard is so complicated that most teams don't, maybe something is wrong with the standard.

- Retraining is not a bad thing. In the end, employees who have seen many different work environments are generally more skilled. You need to think long term, even considering today's lack of loyalty for employers and employees alike.

- One single language is a stupid idea. Use the right tool for the job. For an experience developer, switching languages is not that hard anyways.

Anyways, I don't think point 1 is bad advise, but we also need to apply point 5 to it ;)

Following a standard is not a guarantee of success. Not having a standard to follow is also not a guarantee of failure.

It is possible to succeed without a standard. And it is possible to fail if you do have a standard.

The key is that having standards (not just “a” standard) usually increases your odds of success. To the point that many feel that having standards is a functional requirement.

Reply on news.ycombinator.com