Software Craftsmanship

Software Craftsmanship by Pete McBreen 2001

A book which is a bit more on the softer side after all these last posts about automata. While looking for new books I saw this one referenced quite some time and thought ‘why not read it?’. I will quote some insights from the book and comment on a few of them.

Let’s go:

• learning a new technology is just a normal part of life of a software developer

Software engineering is designed for large projects (100 developer years) but most projects are smaller

I found this insight particular interesting. I read in the Mythical Man Month about the different kinds of models. Systems engineering projects were the one covered there which is new hardware and new software. However, most projects today don’t work that way.

Also it’s interesting that the software engineering process makes a lot of sense for systems engineering projects. Like often, original ideas were adopted poorly.

• Real test of software development not in following best practices but on timely shipping and improving the product in the future

Even with process exceptional developers are vital to project success

That’s also quite interesting. There’s of course one effect which decreases the individual influence with a project with lots of people. Still, most big projects had one or two key people who carried the project.

• Requirements, Design, Programming – hard to split thanks to information passing
• handoffs are the biggest problem
• small teams with great communication

This is quite interesting and something I saw myself. Often handoffs are the biggest problem because information can’t properly communicated. Therefore, the less handoffs the less chances of miscommunication. And even the lack of competence through generalization can be neglected if there’s less miscommunication.

The exploding demand for software developers was met by providing short retraining programs that taught a restricted set of technical skills. Typically these courses were less than six months long and aimed to make people productive enough that they could work on projects. … Both of these approaches failed.
What was missed in this effort was the real craft of software development and al of the programming lore that built up during the 1960s and 1970s. Without this knowledge … projects started to repeat the classical mistakes that  had been made in the past.

The same happened the last years. Coding dojos, coding school, whatever. Basically the same reproduction. Here’s something I think will happen. The programming hype will decline in the next 5 – 7 years and there will be a ton of unmaintainable code. Just like two times before – in the 80s and 00s.

Here’s a wonderful comment by grandalf which covers the idea of the cycle:

I think it’s part of a larger trend in startups. When there is no startup boom, people who do startups do them b/c they love building things. When there is a boom, ambitious people do startups b/c it is part of their calculation of how to achieve power and wealth, the competition for which is a zero sum game.

The true visionaries who build amazing products and companies are not the kind of people who, in the midst of a boom, decide to do a startup instead of applying to a prestigious MBA program. […]

This is just startups becoming mainstream, and attracting the same kind of people that have always gravitated toward iBanking and other MBA oriented fields. Sooner or later some of the startup funding will dry up due to routine, cyclical forces, and the startup scene will once again consist mostly of hackers and builders.

Or like someone said: ‘people doing startups today were the people who did real-estate a few years ago’.

Same goes for programming with the ninjas, brogrammers, etc.

• make the best software for a small number of users
• signing software, get skin in the game

small team of craftsmen instead of large team of average programmers

This is also something I’ve written about in the past. If you don’t want to be a programmer or software dev – don’t do it. Do something you can commit yourself to. I sat at my first computer nearly 20 years ago and programmed for over 9 years. I worked through books, wrote software years ago which is still in use. Blog for quite some time. Am I a coding ninja? No way. There’s always something to learn.

I’ve written my first python code about 7-8 years ago. Do I master python? Nope. Mastery doesn’t mean pretty good. It means incredible great. It means that you spent your time hacking python interpreters. Not writing some django app.

• Fast iteration, deliver early and often
• Automate testing as much as possible

• Craftmanship projects up to 20 developer years

• Software engineering if projects has 200+ developer years

Successful devs will probably be successful in the future

I heard this before in an other industry. Good people will be good. Bad people will be bad. The idea presented in the big is that habit forms how good you will be.

You can change habit – takes about two months – but quite some people won’t change. I’ve seen the typical ‘He can write Cobol in any language’ or ‘He can write Java in any language’ etc. so often. Lately, I checked out some python code of some people on github. What I’ve seen was C/Java style Python.

Embrace change. Force yourself to question what you do. And then you will change.

• Strong user involvement
• User should provide feedback within 24 hours
• Use in-house learning
• Encourage participation in user groups / community

And the final quote which is great:

Software development is meant to be fun, if it isn’t the process isn’t working.