
A discipline for software engineering
by Watts S. Humphrey · first published 1995
10mentions
2recommended by
4HN commenters
2011–2022first – last mentioned
50% recommend50% neutral
This new work from Watts Humphrey, author of the influential book, Managing the Software Process, broadens his orderly view of software process management, and lays the foundation for a disciplined approach to software engineering. In his earlier book, the author developed concrete methods for managing software development and maintenance. These methods, now commonly practiced in industry, provide programmers and managers with specific steps they can take to evaluate and improve their software capabilities. In this new book, Humphrey scales those methods down to a personal level, helping soft
Affiliate links. As an Amazon Associate I earn from qualifying purchases.







…The C Programming Language will be mentioned. These days that means Zed Shaw will be named and hilarity will ensue. Myself? I'd definitely have Code Complete (I still have my first edition), perhaps A Discipline for Software Engineering and Software Estimation: Demystifying the Black Art. I've found pretty much everything from Dorset House to be worth my time, so to PeopleWare I'd add The Deadline and Adrenalin Junkies and Template Zombies.…
on “Books every developer should read” ↗You might find Watts Humphrey's book A Discipline for Software Engineering to be an interesting read. In it he describes a scheme where you track all your mistakes, no matter how tiny, and patiently develop ways to prevent them from happening in future. edit: Look, I know that…
on “What does $1265 of bugs look like?” ↗How and why: Read "Software Inspection" by Tom Gilb Learn by doing: Read "A Discipline for Software Engineering" by Watts S. Humphrey. Skip to the exercises at the back, as 95% of the value is in the exercises, the main book is not that good (wants a re-write). Often, people make the mistake of only doing a code…
on “Ask HN: How can I run an effective code review?” ↗…the mistake. After a while you use your data to correct your common errors with ... checklists! And other tools and practices, of course, but checklists are a big part of the PSP. It's worth reading A Discipline for Software Engineering, even if you never apply it.
on “Software Checklist” ↗You may find A Discipline for Software Engineering by Watts Humphreys to be an interesting read.
on “Test-driven development: A great idea hiding behind a terrible implementation?” ↗Quality control innovations: Requirements reviews, Test driven development, Agile. Have a read of Software Inspection by Tom Gilb. The exercises at the back of A Discipline for Software Engineering are also very good (although the main book is not that good). Edit: It is worth understanding "bugs removed per hour". Every quality control "innovation", has a bug removal rate and will improve the…
on “Ask HN: What should every software engineer know?” ↗Have you considered reading some software engineering classics as well? Code Complete, Rapid Development, The Mythical Man-Month, The Pragmatic Programmer, Peopleware and A Discipline for Software Engineering? (The last one is controversial).
on “Ask HN: How to grow as a Software Engineer?” ↗…identical tasks, and a fairly large amount of time to do them"? That is the specific study I am searching for to add to my list of papers. Did you give me this link because you were referring to Humphrey (A Discipline for Software Engineering), or something else? I can track down Humphrey, but it will take me a few days, since it's a physical book.
on “Study of 49 programmers: static type system had no effect on development time” ↗I bought a used copy of A Discipline for Software Engineering by Watts S. Humphrey, and when I received it, I found that it had been signed by the author as a gift to his brother, Philip S. Humphrey. The inscription reads: "Phil - here's the latest opus - Watts"
on “What’s the strangest thing you ever found in a book?” ↗The old school version of this is called the Personal Software Process, first described in A Discipline for Software Engineering. It was sometimes used as a punchline by early agile advocacy.
on “The Beginner’s Guide to Quantified Self” ↗