Finished Software Craftsmanship
I finished the Software Craftsmanship book. The main points of the book was that software engineering came from building huge massive projects like the space shuttle where hundreds of man years are required to write code for hardware that doesn’t exist yet. Because the hardware doesn’t exist, you needed to spec out the programs after you analyzed it. Coding was the easy part because everything has been figured out. The waterfall model goes top down. You gather the requirements, design, implement, verify and then maintain.
The problem is that this is inappropriate for our present development environment. It’s too slow and doesn’t handle changes in requirements. You need feedback from your users and use that info to drive the specs. You do this by making incremental changes to the code. If you wait until you’re “done”, you run the risk of creating something that the client does not want, or worse a collection of bugs.
Instead of the programmers just implementing a design, they need to have a larger scope of the entire process. In software engineering, the main focus was on the process and engineers are interchangeable. Software craftsmanship says that individual programmers matter. Great programmers can make a dramatic impact to a project. You can develop great programmers through apprenticeship. You need to have that knowledge passed off to the next group of developers. In software engineering, the great programmers were usually promoted to managers and had little to do with programming.
Pretty much the book was preaching to the choir since I agreed with everything it was saying. What programmer wouldn’t agree that great programmers need to be paid more and average programmers less. Unless of course, you’re an average programmer.