5 ms·

This is the best book on software engineering and project management. 1. Need standards for process, coding style, change control, documentation. Must be easy

by RNeff 7y ago

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!

Arrezz 7y ago
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?
QuixoticQuibit 7y ago
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?
- twunde 7y ago
  #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.
joddystreet 7y ago
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".
- twunde 7y ago
  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
  - joddystreet 7y ago
    A software shipped with life-supporting medical equipments, for example, should not have the missing spec problem. Or, I assume so.
    - bradknowles 7y ago
      You’ve heard about the Therac-25, right? That one killed lots of people.
  - joddystreet 7y ago
    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?
  - majewsky 7y ago
    > 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) https://en.wikipedia.org/wiki/Vasa_(ship)
twunde 7y ago
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
GuB-42 7y ago
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 ;)
- bradknowles 7y ago
  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.

by RNeff 7y ago

Arrezz 7y ago

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?

QuixoticQuibit 7y ago

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?

twunde 7y ago
#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.

joddystreet 7y ago

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".

twunde 7y ago
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
- joddystreet 7y ago
  A software shipped with life-supporting medical equipments, for example, should not have the missing spec problem. Or, I assume so.
  - bradknowles 7y ago
    You’ve heard about the Therac-25, right? That one killed lots of people.
- joddystreet 7y ago
  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?
- majewsky 7y ago
  > 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) https://en.wikipedia.org/wiki/Vasa_(ship)

twunde 7y ago

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

GuB-42 7y ago

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 ;)

bradknowles 7y ago
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.