3 ms·
The real value of studying outdated development methodologies is that it teaches you how to think about new problems. It will almost never give you a plug-and-p
by timoth3y 5y ago
The real value of studying outdated development methodologies is that it teaches you how to think about new problems. It will almost never give you a plug-and-play answer for a problem you are facing, but it will give you a new a useful way of looking at things.
Brooks wrote The Mythical Man Month in the 1970s about his experience in the 1960s and it is still extremely relevant today.
When I was starting my software development career in the mid 1990s and trying to understand how to manage the process, one of the things I did was write to NASA and request a copy of their Manager's Handbook on Software Development.
This was not because I wanted to run things like NASA. That would have been be horribly inappropriate for a startup dev team. However, I wanted to understand an extreme; a process where spec writing, testing and on time delivery were prioritized.
I never used anything directly from that NASA handbook, but I learned a lot.
Almost 30 years later, I still have that book. It's one of my little treasures.
- yourapostasy 5y agoFor those wondering, there is the original handbook [1] available online today. Also an interesting paper on the process improvement lessons learned applying much of what was expressed in the handbook [2]. I believe the paper is of more immediate TL;DR use today for those who do not have the time to digest the handbook and internalize the lessons to draw from it. [1] https://everythingcomputerscience.com/books/nasa-manage.pdf https://everythingcomputerscience.com/books/nasa-manage.pdf [2] http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/83.88.pdf http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/83.88.pdf
- timoth3y 5y agoThat's the one! Thank you for posting the link and the lessons learned. That looks like a great article. In the 90s it took a (very friendly) FOIA request, a $5 processing fee, and three weeks to get my hands on that handbook.
- bdavis__ 5y agocurious if anyone tracks software engineering metrics like this anymore? defects identified, defect fixed vs. time
- Jtsummers 5y agoYes. However, it's mostly in "maintenance" programming. Particularly in the way that DOD and safety critical systems are maintained. It's both a reasonable and unreasonable concept. It's unreasonable because it tries to turn programming into factory work, in fact you may even see them set up workflows predicated on an assembly line concept. This kind of works, and why it's kind of reasonable, when the work is sufficiently well-understood. It's very common in these systems to have a very detailed specification. Often the defects are deviations from the specifications that got through because of the manner in which these were classically tested (primarily integration tests, often manual, necessarily restricting the scope of the testing regimen). Other defects are realizations that the specification itself has an issue (happens), often the result of a dependence on a prose format for the specification which doesn't lend itself well to formal analysis. It also tends to, well, become wordy. 1000 page specs are not unheard of even for relatively small systems, you can imagine there may be quite a few pieces of conflicting information in there.
- secondcoming 5y agoWas that book about the Capability Maturity Model? [0] [0] https://en.wikipedia.org/wiki/Capability_Maturity_Model https://en.wikipedia.org/wiki/Capability_Maturity_Model
- urthor 5y agoThe analogy of programmers as general surgeons is so timeless it's downright creepy. Nothing has changed in Brook's book because it's a book about human beings doing creative work, and humans haven't changed at all.