Category Archives: war stories

Making your software “production ready”

Posted on by
1

At yesterday’s meeting, we had a discussion about how to improve the way we run the group and encourage more folks to come along. Steven was at the forefront of these ideas and said that he thought that reading a book a month was really too much. He also thought that concentrating on the book puts people off, even though we explicitly say that you don’t need to have read the book to come along. So we are going to make a handful of changes going forward:

  • We will only read a new book every 2 months.
  • The meetings in between we will go back and look again at a book we have covered before. This will give new folks a chance to discuss a book they missed. It will also give anyone who didn’t manage to finish the book a chance to get to the end. And finally it will allow us to look at how the book actually influenced the way we develop software.
  • We will place less emphasis on the books. We will make it clearer that the discussion will merely use the book as a starting point and that we’ll be talking about the topic of the book, not just the words within it. Hence the title of this posting.

So, back to last night’s meeting. Joining me to discuss Release It! were Tom, Steven, Jocelyn, John and Ursula. Tom kicked off by saying that he hadn’t realised beforehand that it was about making your software robust for real life usage. But once he started reading it he found it hard to put down. Lots of it rang true and reminded him of situations he had been in before. On the down side, he felt that the stories were a little predictable after a while.

I pointed to the “Circuit Breaker” pattern as one that I found very interesting. This seems to be the one that has generated the most interest judging by the postings on the book’s forum. I also found a description of this pattern implemented as a Spring aspect.

Tom was also keen on the Bulkhead and Decoupling Middleware patterns. Something he thought was missing was a discussion of splitting up a large system into separate components so that you could shut down individual components and leave everything else running. This wouldn’t even have to be something as sophisticated as OSGi.

Steven said that he was looking for ideas to make his new mobile “Good Beer Guide” service stable. Unfortunately he didn’t get too far, which is ironic since he was the main person advocating this book.

Tom said that when he used to be a sys admin it was great to have data about the systems you are looking after. So when a problem arises and someone says “the network’s having problems”, you can open up your dashboard and say “Nope, look at the data”. He liked the story about ‘Voodoo Operations’ where the database kept being restarted just for luck (p280). Tom said he’d experienced people doing this sort of thing for real.

Ursula liked the discussion about making log files easy to read (p279). This seemed like a very simple idea, but a powerful one. John said that all this sort of thing had been done in the 80′s, but that when PCs and Unix took over from mainframes the whole financing of software changed. So that quick and dirty was the order of the day. But now we are going back to those roots.

Ursula said that she found the whole section on Capacity very interesting. In her experience that sort of work has always been left to experts to deal with at the end of a project whereas it might make more sense to think about this from the start. She did however find that the book was very focussed on web applications and mainly on Java. But she thought the references (internally forward and backward) were very well put together.

Meeting 15 – Dreaming in Code

Posted on by
Reply

I think this meeting must have set the record for the number of people who read the book but couldn’t make it along. As I mentioned before, Steven, the person who kept suggesting this book had already read it and posted a review to his blog.

So it was just down to me, Tom and Miquel to discuss Dreaming in Code at the pub. Our discussion was quite short as much of the book covers areas that are well known to software professionals. Miquel kicked off by pointing out that it covered quite a lot of the history of software. There are mentions of Fred Brooks, Dijkstra and Knuth in there.

Tom said that he had downloaded the current version of Chandler (they are at version 0.7) to have a play with. He couldn’t get it to work because it insisted on having an IMAP account to connect to. Otherwise he found it to be much like an ordinary email client.

Miquel said he thought that the project was too ambitious. I agreed but also suggested that one of the problems was that it was too wooly. The spec was little more than “The Soul of Agenda”. In Miquel’s opinion there was too much talk and not enough coding. Tom pointed to the fact that they seemed to spend all of their time building frameworks to do this, that and the other.

I knew that Steven was talking about giving this book to his wife to explain what his job is about. So I asked if people thought it would be a good book for non-coders. Tom wasn’t really sure. He thought that the sections aimed at the non-technical reader would be boring for the technical reader and vice versa. I thought it was pretty good from that angle, but I’m sure how gripping it would be for someone not involved in software development.

Tom thought that the best parts of the book were the short essays that were scattered through it. He would have preferred just to have read them. The story of Chandler was secondary as we already knew how that was going to turn out. Miquel suggested that the Chandler project was just an excuse to write the book.

Finally, I pointed out that it was odd that in the chapter ‘Engineers and Artists’, the author didn’t mention the collection of essays by Paul Graham with almost the same title ‘Hackers and Painters’. The essay which gives its name to the collection covers many of the same themes, especially the debate about whether software development is science/engineering or art/craft.

Second Meeting – The Mythical Man-Month by Frederick Brooks

Posted on by

Meeting once more in Far from the Madding Crowd, there were more of us in attendance than last time. In addition to Chris, Steven and myself from the first meeting, we were joined by John, Miquel, Jim and Stephen.

We began with Chris pointing out how the book described another world of programming to that we were familiar with, the 60s and 70s of Brooks’ experience. A place where documentation could be measured in feet, where secretaries could potentially be typing up the alterations to a new version of a manual every day. Where hardware development was a lot closer to software development. This perhaps was a barrier of entry in terms of understanding for some of the more esoteric parts of the book.

It was then mentioned how the language of the book was not always clear. For instance:

One rarely controls the circumstances of his work, or even its goal. In management terms, ones’ authority is not sufficient for his responsibility. It seems that in all fields, however, the jobs where things get done never have formal authority commensurate with responsibility
P8 The Mythical Man-Month

This was a confusing concept for us, perhaps as we all mainly seem to be used to working in small teams, and responsibility being much closer to us the majority of the time

We talked about the concept raised by Brooks that with manufacturing, if there is an error with a product, it is quickly apparant what is to blame. In software development it is harder to find the blame. It was pointed out by both Jim and Chris that it was in fact very easy, you just blamed Microsoft, Oracle, Apple, a passing DBA, anyone or anything.

Chris brought up the point he made previously on this blog about how Brooks seemed to use the terms Debugging and Testing interchangeably. Steven commented that it was possible that in his day, the only way of testing could reasonably have been to run a program through a debugger.

The Surgical Team suggested as an ideal in the book (p36) was suggested as obviously overkill in this day and age. A lot of the functions that were covered by individuals in this team are now automated, such as properly self-documenting programmes. However, I pointed out that the concept of having a pilot and a co-pilot, with the co-pilot checking the pilot’s code, sounded an awful lot like paired programming, just without switching the roles regularly. It certainly accepts the principle that even allowing for a “superstar” programmer in charge, that their code can only benefit from peer review, a second set of eyes.

Staying with the concept of teams, Miquel raised Brooks’s Law

Adding manpower to a late software project makes it later
P25

Which was felt to be a fairly obvious point, made even more obvious by his later clarification that this did depend on the skill of the people you added. Again though, it was clear from our discussion that as we all come from smaller teams, we are not used to the needs of a significantly larger project. Brooks himself does suggest that the ideal is a small team of experts, but in order to get a large project to completion, more often you will require a large team of a range of quality, in effect arriving at an appropriate solution through more volume and brute force than from skill and design.

Mention is also made of being prepared on the design side to design your initial model, and then to throw it away in favour of a better model once you have more knowledge of and familiarity with your project. Whilst this concept of not being tied to the initial model is reflected in an XP approach, XP suggest a refactoring approach of constantly improving the model.

Moving on to the essay No Silver Bullet, perhaps the concept that most irked Chris and myself was the following statement:

I believe the single most powerful software productivity strategy for many organizations today is to equip the computer-naive intellectual workers on the firing line with personal computers and good generalized writing, drawing, file and spreadsheet programs, and turn them loose.
P199

I have spent too much time in my days in support dealing with accidently deleted files, user-imposed password protection on documents belonging to left users, and a myriad of poor design choices to agree with this. I described this approach as “Let them eat Excel”

Jim brought up the somewhat pessemistic tone of the whole book, that there truely was no silver bullet, and that these words do firmly hold true today. We discussed several potential silver bullets of the past, and that the general fault, as identified by Steven, was that they often tended to be great solutions as long as what you wanted them to achieve was within the narrow design remit they had assumed, and that as soon as you needed something outside of this remit, the amount of work required to get around the restrictions would almost always outway the benefits you had initially gained.

The comment of Martin Fowler that “You can’t measure productivity” was brought up in the context of Brooks’s attempts to do just that. This was in an age where productivity was being measured in terms of words written in code, rather than lines of code written. However, reflected in the light of refactoring, code could also be judged in terms of lines removed, of the brevity of the code. The smaller and neater the better, in some regards.

Chris brought up the concept from the book that Maintenance was Decay:

All repairs tend to destroy the structure, to increase the entropy and disorder of the system.
P122

This again doesn’t equate to the improvements one would expect from incremental design and refactoring, so was quite an alien concept to us. However most agreed that the concepts from the book that were still relevant were the issues of communication and team work Brooks describes. Possibly where the technical aspects of software development have constantly developed for decades, the principles of teams, management and organisation are slower to move on, having been around for much longer.

I think it is fair to say that we deliberately read this book from a modern point of view, and in some cases were reading it against some of the principles of XP and Agile development. So we were likely to be more critical, and we were. However it was also apparent that some aspects of developement are still as Brooks suggested, and that some ideas for XP and Agile were slightly foreshadowed by him many years before.

All in all, a successful meeting, more attendees, and a lot of ideas and points were raised by everyone, and I look forward to see what we make of our next book

Please feel free to correct me on any inaccuracies in my recollections of our meeting, or to discuss the points I have recorded.