Mark Needham

Thoughts on Software Development

Archive for the ‘Books’ Category

Books: Know why you’re reading it

with 2 comments

Something which I frequently forget while reading books is that it’s actually quite useful to know exactly why you’re reading it i.e. what knowledge are you trying to gain by doing so.

I noticed this again recently while reading The Agile Samurai – it’s one of the books we ask ThoughtWorks University participants to read before they come to India.

Implicitly I knew that I just wanted to get a rough idea of what sort of things it’s telling people but I somewhat foolishly just started reading it cover to cover.

I only realised that I’d been doing this when I’d got a third of the way through and realised that I hadn’t really learnt that much since the book effectively describes the way that ThoughtWorks delivers projects.

In Pragmatic Learning and Thinking Andy Hunt suggests the SQ3R reading comprehension method which I always forget about!

  • Survey – scan the table of contents and chapter summaries
  • Question – note any questions you have
  • Read – read in entirety
  • Recite – Summarise and take notes in your own words
  • Review – Re-read, expand notes, discuss with colleagues

I don’t think it always needs to be quite as organised as this but I’ve certainly found it useful to scan the chapter headings and see which ones interest me and then skip the ones which don’t seem worth reading.

When reading The Art of Unix Programming I felt that I was learning a lot of different things for the first ten chapters or so but then it started to get quite boring for me so I skimmed the rest of the book and ended up reading just half of the chapters completely.

The amusing thing for me is that I knew about this technique a couple of years ago but I still don’t use it which I think that comes down to having a bit of a psychological thing about needing to finish books.

At the moment I have around 15 books which I’ve partially read and at the back of my mind I know that I want to go and read the rest of them even though there will undoubtably be varying returns from doing that!

I need to just let them go…

Written by Mark Needham

February 26th, 2011 at 3:06 am

Posted in Books

Tagged with

The Adventures of Johnny Bunko – The Last Career Guide You’ll Ever Need: Book Review

with 3 comments

I read Dan Pink’s A Whole New Mind earlier in the year but I hadn’t heard of The Adventures of Johnny Bunko until my colleague Sumeet Moghe mentioned it in a conversation during ThoughtWorks India’s XConf, an internal conference run here.

The book is written in the Manga format so it’s incredibly quick to read and it gives 6 ideas around building a career.

I’m generally not a fan of the idea of ‘building a career’ – generally when I hear that phrase it involves having a ‘five year’ plan and other such concepts which I consider to be pointless.

I much prefer to just focus on what I’m most interested in at the moment and then have the flexibility to be able to focus on something else if that interests me more.

Luckily this book is not at all like that and these are the ideas Dan Pink suggests:

There is no plan

The most interesting part of this piece of advice is Pink’s suggestion that when we make career decisions we make them for two different types of reasons:

  • Instrumental reasons – we do something because we think it’s going to lead to something else regardless of whether we enjoy it or think it’s worthwhile.
  • Fundamental reasons – we so something because it’s inherently valuable regardless of what it may or may not lead to.

I think this pretty much makes sense – it’s very difficult to predict what’s going to happen so you might as well make sure you’re doing what you want at any given time.

Think strengths not weaknesses

Marcus Buckingham has several books on this subject but the general idea is that we should look to focus on things that we’re good at or are really motivated to become good at.

By inference this means that we want to avoid spending time on things that we’re not good at and/or not interested in becoming good at.

I recently came across a blog post written by Robbie Maciver where he suggests that we can use a retrospective to help us identify team member’s strengths and work out how best to utilise them.

I think there’s sometimes a reluctance for people to volunteer their strengths so we end up with people working on tasks that they hate that other people in the same team would enjoy.

It’s not about you

Pink then goes on to point out that even if we do work out how to play to our strengths we still need to ensure that we’re focusing on our customer/client.

Pink calls this focusing outward not inward.

In terms of working in technology consulting that would therefore be along the lines of ensuring that we’re focused on solving our clients’ problems in the best way for them rather than the most interesting way for us.

Persistence trumps talent

This idea has been covered in several books including Outliers, Talent is Overrated and The Talent Code.

The underlying idea is that people aren’t born brilliant at any skill, it only comes through practice and if we’re intrinsically motivated to do something then we’re much more likely to put in the time it requires to become really good.

To add to that I think intrinsic motivation is highest when we’re focusing on our strengths so this piece of advice is linked with the earlier one.

Make excellent mistakes

Pink talks about making excellent mistakes which he describes as ‘mistakes that come from having high aspirations, from trying to do something nobody else has done’.

I think this is somewhat linked to the idea of failing fast although it seems to be perhaps one level beyond that.

Sumeet gave a talk at XConf where he described the new approach to ThoughtWorks University and pointed out that one of the most important goals was to allow attendees to make ‘excellent mistakes’

One observation I have here is that smaller companies seems more willing to make excellent mistakes. As organisations grow the aversion to risk because of worries about loss of reputation increases which makes excellent mistakes less likely.

I find Eric Ries’ lean startup ideas particularly interesting with respect to failing fast and my former colleague Antonio Terreno recently linked to a video where the General Manager of Forward 3D explains how they do this.

Leave an imprint

Pink talks about the importance of doing work which actually has some meaning or leaves the world in a better place than it was before.

This is probably the one that I can relate to least. I’m writing software which is what I’m passionate about but I wouldn’t say the problems I work on are having much impact on the world.

This one therefore leaves me with the most to think about.

Written by Mark Needham

November 21st, 2010 at 5:02 pm

Posted in Books

Tagged with

Linchpin: Book Review

with 5 comments

I’ve read a couple of Seth Godin’s other books – Tribes and The Dip – and found them fairly readable so I figured his latest offering, Linchpin, would probably be worth a read too.

51fMyB3O1TL._SL500_AA300_.jpg

This is the first book that I’ve read on the iPad’s Kindle application and it was a reasonably good reading experience – I particularly like the fact that you can make notes and highlight certain parts of the text.

It’s also possible to see which areas of the book other Kindle users have highlighted and you can see your highlights/notes via the Kindle website.

The Review

The sub-title of the book: ‘Are you indispensable? How to drive your career and create a remarkable future’ didn’t really appeal to me all that much but I’ve found that these types of things are often just for provocation and don’t necessarily detract from the message.

As with the other Godin books I’ve read, he spends a lot of time making his original point and in this one it felt like I’d already agreed with what he was saying for at least 50 pages before we moved onto something else.

Despite that I think there were some good points made in the book. These were some of the more interesting ones for me:

  • One of my favourite quotes from the book is the following about fire:

    Fire is hot. That’s what it does. If you get burned by fire, you can be annoyed at yourself, but being angry at the fire doesn’t do you much good. And trying to teach the fire a lesson so it won’t be hot next time is certainly not time well spent.

    Our inclination is to give fire a pass, because it’s not human. But human beings are similar, in that they’re not going to change any time soon either.

    One of the things I’ve noticed over time is that it’s very unlikely that the core way a person behaves is likely to change regardless of the feedback that they get from other people.

    Pat touches on this in a post where he points out that we need to be prepared for feedback to not be accepted.

    I don’t think this means we should stop giving feedback to people if we think it will help them be more effective but it does seem useful to keep in mind and help us avoid frustration when we can’t change a person to behave in the way we’d like them to.

  • Godin makes an interesting point about the value of the work that we do:

    A day’s work for a day’s pay (work <=> pay). I hate this approach to life. It cheapens us.

    This is exactly the consulting model – billing by the hour or by the day – and although I’ve come across a couple of alternative approaches I’m not sure that they work better than this model.

    Value based pricing is something which I’ve read about but it seems to me that there needs to be a certain degree of trust between the two parties for that to work out. The other is risk/reward pricing and I’ve heard good/bad stories about this approach.

    It seems to me that we’d need to have a situation where both parties were really involved in the long term outcome of the project/system so if one party is only invested for a short % of this time then it’s going to be difficult to make it work.

  • Shipping is another area he touches on in a way that makes sense to me:

    I think the discipline of shipping is essential in the long-term path to becoming indispensable.

    The only purpose of starting is to finish, and while the projects we do are never really finished, they must ship. Shipping means hitting the publish button on your blog, showing a presentation to the sales team, answering the phone, selling the muffins, sending out your references. Shipping is the collision between your work and the outside world.

    While this is just generally applicable, in software terms this would be about the sort of thing that my colleagues Rolf Russell & Andy Duncan cover in their talk ‘Rapid and Reliable Releases‘.

    I also had an interesting discussion with Jon Spalding about the importance of just getting something out there with respect to the ‘Invisible Hand‘ browser plugin that he’s currently working on. Jon pointed out that it’s often best to ship and then rollback if there are problems rather than spending a lot of time trying to make sure something is perfect before shipping.

  • Godin spends a lot of time pointing out how important human interactions and relationships are and I think this is something that is very important for software delivery teams. One of the most revealing quotes is this:

    You might be parroting the words from that negotiation book or the public-speaking training you went to, but every smart person you encounter knows that you’re winging it or putting us on.

    Virtually all of us make our living engaging directly with other people. When the interactions are genuine and transparent, they usually work. When they are artificial or manipulative, they fail.

    I attended a consulting training course when I first started working at ThoughtWorks 4 years ago and I’ve always found it impossible to actually use any of the ideas because it doesn’t feel natural. It’s interesting that Godin points out why this is!

Overall this book feels to me like a more general version of Chad Fowler’s ‘The Passionate Programmer‘ which is probably a more applicable book for software developers.

This one is still an interesting read although it primarily points out stuff that you probably already knew in a very clear and obvious way.

Written by Mark Needham

July 12th, 2010 at 4:07 pm

Posted in Books

Tagged with ,

Maverick: Book review

with 5 comments

My colleagues Frankie and Danilo have been recommending ‘Maverick‘ to me for a long time and I finally got around to reading it.

In this book Ricardo Semler, the CEO of Semco, tells the story of the company and how he helped evolved the organisation into one which is more employee led and embraces ideas such as open & self set salaries while encouraging civil obedience in the workforce as a necessity to alert the organisation to its problems.

These were some of the ideas that I found the most interesting:

  • Early on Semler points out that Semco doesn’t have a culture of looking busy. He describes how a sales manager spends a lot of his day just reading the newspaper but then as soon as there’s a problem for him to handle that’s when he earns his salary. Even though this book isn’t specifically about systems thinking, the description of this situation suggests to me that they are able to look at the bigger picture at Semco.

    In software teams we can often feel quite guilty if we’re not busy but a bit of slack time is often useful for thinking about better ways to do things or to spike out new ideas.

  • Semler emphasises the need to have small business units of under 150 people while matches up quite well with research done by Robin Dunbar which indicates that 150 is the ‘theoretical cognitive limit to the number of people with whom one can maintain stable social relationships.’ Semler also adds that keeping the units small ‘keeps them human’.

    I know ThoughtWorks keeps this in mind with respect to our offices and will look to open a new one if the number of people in one is getting close to the 150-200 mark.

  • Semco have a culture of what Semler refers to as ‘absolute trust‘ which he suggests is a more natural way. They implemented this at Semco by removing security checks on the gates into/out from the plants.

    He almost then predicts the inevitable question in the reader’s mind with the following statement:

    2 or 3% will take advantage of an employer’s trust. Is this a valid reason to subject 97% to a ritual of humiliation?

    Have thefts increased or decreased?

    I don’t know and I don’t care. It’s not worth it to me to have a company at which you don’t trust the people with whom you work.

    He promotes an approach of common sense amongst his employees, suggesting that ‘rules freeze companies inside a glacier; innovation lets them ride sleighs over it’.

    The general idea seems to be that the small details aren’t really that important and only serve to distract from the bigger objectives that the company are trying to achieve.

  • I was quite surprised to read how strongly Semler recommends job rotation:

    Man is by nature restless. When left too long in one place he will inevitably grow bored, unmotivated, and unproductive. The cure, I believed, was to encourage managers to exchange jobs with one another

    He goes on to point out that this type of rotation forces people to learn new skills which makes them more valuable but also discourages empire building because people don’t stay in the same place for too long.

    I think we do this to some extent in the software industry between some roles but probably not as much as we could do. Having said that there is a lot to learn as a developer anyway so perhaps it’s not so applicable here.

  • Perhaps the most controversial idea in the book is that of transparent/self set salaries. There was initially resistance to the latter idea as cynics believed that a few people would take advantage and award themselves massive pay increases. However, they found that having those salaries public served as a strong disincentive.

    He also identifies the fact that people have a stake in the success of the company as being key for allowing this to work:

    The third reason our people tended to be modest about salaries has to do with self preservation…Our people know salaries account for most of our operating costs, and they think about our budgets when they set them. It’s easy to solve a budget problem by eliminating a salary that seems too high, and noone wants to stick out.

  • The underlying reason behind why a lot of the ideas Semler implements seem to be about unhiding information as described by the following quote:

    There is power in knowing something someone else doesn’t…but when cards are held close to the chest, communication will be faulty and anxieties, misunderstandings, insecurity, and eventually hostility will manifest itself…which is why when we started sharing information at Semco it has such a profound effect. People in the higher echelons could no longer rely on the conventional symbols and had to develop leadership skills and knowledge to inspire respect.

    Spreading responsibility for problem solving across the organisation is another idea Semler strongly encourages and I think this partly explains why it’s more fun working in an agile environment.

    Information in general is more accessible and because of that people have more opportunity to solve problems than they otherwise would.

  • Semler discusses the need to keep the organisation lean even when times are good which he acknowledges is much more difficult than trying to keep it lean when times are hard! For Semco this involves being careful when hiring people to work on product lines which they knew had a short life span as well as ensuring that they didn’t add any unnecessary roles just because sales were strong.

Towards the end of the book Semler suggests that his goal with Semco was to ‘make people look forward to coming to work in the morning‘ which seems like quite a noble objective!

I found it quite interesting that although a lot of these ideas seem a bit radical, they made sense in Semco’s context because they were introduced incrementally and only after some other ideas had been introduced which helped smooth the way.

It’s certainly an interesting read and the ideas expressed at quite different than what is typical in most organisations.

Written by Mark Needham

April 14th, 2010 at 7:23 am

Posted in Books

Tagged with

Getting real: Book review

with 2 comments

I recently came across 37 Signals ‘Getting Real‘ book where they go through their approach to building web applications and there have certainly been some good reminders and ideas on the best way to do this.

These are some of my favourite parts:

  • Ship it!

    If there are minor bugs, ship it as soon you have the core scenarios nailed and ship the bug fixes to web gradually after that. The faster you get the user feedback the better.

    Often on projects I’ve worked on we’ve taken the approach that bugs get worked on before new stories which makes sense in a way because it means that we are fixing problems quickly and keeping the quality of the application high.

    In reality what often happens is that low priority bugs just end up not getting looked at but I like the fact that we can choose to make that an explicit approach rather than just allowing it to happen to us.

    Prioritize your bugs (and even ignore some of them)

    Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life.

    I find it interesting that there might be more value in getting something out the door and then getting feedback on it rather than spending extra time perfecting it up front.

  • Fix Time and Budget, Flex Scope

    You have to figure out what’s really important. What’s going to make it into this initial release? This forces a constraint on you which will push you to make tough decisions instead of hemming and hawing.

    From my experience a lot of times we end up implementing features just because that’s what was agreed in the initial release plan and there is often a reluctance to change that even if a feature isn’t really that useful anymore.

    It becomes even more problematic if we get to the stage where it’s not possible to deliver all the features promised in the remaining time so it certainly makes sense to me that in that situation we would look to focus on getting the absolutely essential things in first.

  • Choose any enemy

    Sometimes the best way to know what your app should be is to know what it shouldn’t be. Figure out your app’s enemy and you’ll shine a light on where you need to go.

    This seems to be a much better idea than just copying the ideas of your competitor which might seem the obvious thing to do if you’re working in the same area.

    The problem with that approach of course is that when you do copy you have no actual vision of what you’re doing with your application anyway so you’ll always be playing catch up.

  • Don’t overcomplicate the application

    There are a few parts of the book where the authors talk about keeping the application simple and then letting the users play with it:

    The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.

    Keep it small. Keep it simple. Let it happen.

    Andrew Hunt, The Pragmatic Programmers

    The users can then decide for us where we need to fill in more details:

    Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.

    In particular they suggest that focusing on very specific details about the page layout/colour/wording can be left until later because it will only serve to hinder forward progress if we concentrate on it too early.

  • Scaling an application

    You don’t have a scaling problem yet

    “Will my app scale when millions of people start using it?”

    Ya know what? Wait until that actually happens.

    On several projects that I’ve worked on there often seems to be a desire to focus on performance and scaling an application very early on which seems wasteful when we could be focusing on actually building something that has so many users that we need to scale it later on. I think this advice is spot on.

  • Write less software

    A common theme throughout the book is that of writing less software to achieve our goals:

    The best designers and the best programmers…are the ones that can determine what just doesn’t matter.

    That’s where the real gains are made.

    Most of the time you spend is wasted on things that just don’t matter. If you can cut out the work and thinking that just don’t matter, you’ll achieve productivity you’ve never imagined.

    Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.

    Throw away customer feature requests – if they’re really important then they’ll come back anyway

    Don’t worry about tracking and saving each request that comes in. Let your customers be your memory. If it’s really worth remembering, they’ll remind you until you can’t forget.

    The authors ideas around preferences were particularly interesting to me:

    Preferences are also evil because they create more software.

    More options require more code. And there’s all the extra testing and designing you need to do too.

    I hadn’t appreciated until recently quite how much complexity we can add to an application by allowing users to play around with the display of information on a screen.

    It seems like a nice feature to have but it would be interesting to see statistics that could tell us what percentage of users actually that type of thing when it’s not the core idea of the application.

    I also quite liked the following and I think it’s something that we need to do more often on teams:

    Encourage programmers to make counteroffers.You want to hear: “The way you suggested will take 12 hours. But there’s a way I can do it that will only take one hour. It won’t do x but it will do y.” Let the software push back. Tell programmers to fight for what they think is the best way.

  • Decisions are temporary so make the call and move on

    So don’t do the “paralysis through analysis” thing. That only slows progress and saps morale.

    Instead, value the importance of moving on and moving forward. Get in the rhythm of making decisions. Make a quick, simple call and then go back and change that decision if it doesn’t work out.

    I think a big part of this is getting the mentality that it’s fine to make changes after we’ve ‘finished’ something. Any other approach doesn’t work from my experience.

  • Reduce meetings

    Meetings usually arise when a concept isn’t clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or im or Campfire.

    I find it interesting that they prefer communicating by email because I’ve often found that it’s not the best communication mechanism since it’s really easy to misinterpret what people mean.

    Having said that if we can make concepts clearer and the need for a meeting is an indicator that we need to do that then perhaps we can still meet in person and just make the meeting much shorter.

  • Design the interface before you start programming

    Too many apps start with a program-first mentality. That’s a bad idea. Programming is the heaviest component of building an app, meaning it’s the most expensive and hardest to change. Instead, start by designing first.

    I’ve certainly fallen into this trap a lot but I’ve been trying to follow the outside in approach more strictly recently and so far I’m finding that it reduces the feedback cycle quite substantially which is only a good thing.

  • Design for regular, blank, and error states

    For each screen, you need to consider three possible states:

    Regular
    The screen people see when everything’s working fine and your app is flush with data.

    Blank
    The screen people see when using the app for the first time, before data is entered.

    Error
    The screen people see when something goes wrong.

    I’d never even though of this at all and I’m certainly guilty of only ever considering applications when all the data is filled in so this is certainly something else to consider.

  • Tear down the walls between support and development

    In the restaurant business, there’s a world of difference between those working in the kitchen and those out front who deal with customers. It’s important for both sides to understand and empathize with the other. That’s why cooking schools and restaurants will often have chefs work out front as waiters so the kitchen staff can interact with customers and see what it’s actually like on the front lines.

    My colleague Chris Read and some others seem to be trying to close this gap with the devops movement which also has a track at QCon London this week.

    The idea of working in support to see what an application is like from that perspective is something that more experienced colleagues often recommend although I’ve not done it as yet.

Overall I found this book a really interesting and quick read and although many of the ideas suggested seem like common sense it’s strange that we often don’t do all of them.

The 37 Signals guys also have a new book coming out in the UK tomorrow titled ‘Rework‘ which sounds like it could be quite a good read as well.

Written by Mark Needham

March 8th, 2010 at 9:56 pm

The Last Lecture – Randy Pausch

without comments

I recently watched Randy Pausch’s ‘Last Lecture: Achieving Your Childhood Dreams‘ and read the corresponding book and although it’s not directly related to software development I think that some of the points that he makes are really intriguing.

These were some of the parts that particularly stood out for me:

  • Introduce the elephant in the room – whatever it is that people are really thinking about, put it out in the open. I think on development teams there is often a distrust of the way that other people write code because it’s different to the way that we do. If we can get this out in the open more frequently and agree on a shared approach then it should result in a more consistent code base.
  • Get the fundamentals down – Pausch suggests that we need to understand the fundamentals because otherwise the fancy stuff isn’t going to work. In Apprenticeship Patterns Ade Oshineye and Dave Hoover suggest that we should ‘Study the Classics‘ which is a similar idea.

    While I think they’re certainly right I’m not sure that learning theory before putting it into practice is the most effective way to learn. I think we need to do a bit of both at the same time alternating between the two so that we actually have a frame of reference when we’re learning the fundamentals.

  • The brick walls are there for a reason – Pausch describes how we’ll often come across obstacles stopping or blocking us from what we want to do but that we shouldn’t be discouraged, they are there so that we can see how much we really want something. I think this is just generally true and not just related to software development.
  • The skill of self assessment – Pausch suggests that we need know what we don’t know which I think is perhaps the best advice in the book. We need to recognise our true abilities but also have a sense of our flaws and create feedback loops to allow this to happen.

    My colleague Liz Douglass has come up with the idea of Feedback Frenzies to help create this feedback loop and this is one of the best ideas I’ve come across for doing this.

  • One of my favourite quotes from the book is the following which I believe was originally from Dan Stanford:

    Experience is what you get when you didn’t get what you wanted

    It’s a phrase worth considering at every brick wall we encounter, and at every disappointment. It’s also a reminder that failure is not just acceptable, it’s often essential.

    I think we can do this much more in the software world. There sometimes seems to be a stigma with identifying things which fail but I think it’s really useful for others to learn from mistakes that have been made.

The Last Lecture is one of the best presentations I’ve had the chance to watch – I’d certainly recommend it.

Written by Mark Needham

January 1st, 2010 at 2:32 pm

Posted in Books

Tagged with

Debug It: Book Review

with one comment

David Agans’ ‘Debugging‘ is the best debugging book that I’ve read so I was intrigued to see that there was another book being written on the subject.

Paul Butcher offered me a copy of the book to review so I was keen to see whether it was more like ‘Debugging’ or ‘Release Itas Ted Neward suggests.

The Book

Debug It by Paul Butcher

The Review

Much like Krzysztof Kozmic I found that a lot of the ideas early on in the book were similar to what I’ve been taught by my ThoughtWorks colleagues over the last 3 1/2 years.

I do think it’s really good seeing these ideas in words though because it’s quite easy to forget about the best way to approach problems in the heat of the moment and the approaches suggested by Paul certainly aren’t done everywhere in my experience.

These were some of my favourite parts of the book:

  • When chasing a bug Butcher suggests that a useful technique to use is to try and disprove your theory of why the problem has happened. Too often we come up with a theory and just adapt any data to fit our thinking. This is also known as confirmation bias.

    In his talk ‘Pimp my architecture‘ Dan North suggests a similar approach more generally when working out how to tackle any problem. Each person has to take the other person’s argument and then fight for that to be used instead. I quite like this idea – certainly something to try out.

  • When discussing the need to refactor code as we go along, the author points out that if the code we want to change doesn’t have any tests around it then we need to write some to provide us with a safety net.

    Remember, however, that refactoring crucially depends upon the support of an extensive suite of automated tests. Without tests, you’re not refactoring. You’re hacking.

    Hamlet D’Arcy makes a similar point but perhaps more forcibly in a really good blog post and Michael Feathers’ ‘Working Effectively With Legacy Code‘ covers the topic in much more detail.

  • One tip which seems obvious but is still one I’ve tripped up on many times is to go through the list of changes that we’ve made before checking in! It’s incredibly easy to forget about some seemingly insignificant change that we made before checking it in and perhaps breaking our application unexpectedly.

    Somewhat tied in with this is the idea of checking in small changes more frequently and only changing one thing at a time which I wrote about previously.

  • I like that Butcher puts a lot of emphasis on ensuring that we actually know what’s going wrong before we attempt to fix anything.

    Without first understanding the true root cause of the bug, we are outside the realms of software engineering and delving instead into voodoo programming or programming by coincidence.

    This is particularly true when addressing performance problems where he rightly suggests that we should look to profile the code before making a premature optimisation.

    He also suggests using the debugger so that we can get a good idea about what the code is actually doing when it’s running. While I think this is useful I feel that the need to use the debugger in this way frequently might suggest that our code is difficult to reason about which could well be something to address.

  • A couple of other cool suggestions are to call on team mates to help us out if we’re getting stuck trying to fix a bug and if that’s not possible then to either write out the problem or talk to the rubber duck.

    If you don’t have someone to play the role of cardboard cutout, all is not necessarily lost. Try scribbling down a narrative of the problem on paper or perhaps composing an email to a friend. The trick is not to censor yourself — just like a writer would.

    I don’t think the importance of communicating with team mates can be underestimated and Butcher points out that if we notice a bad pattern in the code than it’s no good just going through and changing it everywhere. We need to talk with the rest of the team to decide whether we can get an agreement on the way we’ll develop code going forwards.

  • The only idea I disagreed with is that of putting assertions into the code which I feel adds clutter to our code even though it makes it fail faster than would otherwise be the case. From my experience if we write good enough unit tests and have good logging in our code then the assertions aren’t needed.

In Summary

The book is pretty quick to read at around 200 pages and packs a lot of useful tips into that space. I’d say it’s a pretty useful book to keep by your desk to refer to now and then.

Written by Mark Needham

December 24th, 2009 at 5:26 am

Posted in Books

Tagged with ,

Fundamentals of Object-Oriented Design in UML: Book Review

with 5 comments

One of my favourite recent blog posts is one written by Sammy Larbi on coupling and cohesion and while discussing it with Phil he suggested that I would probably like this book and in particular the chapter on connascence which I’ve previously written about.

The Book

Fundamentals of Object-Oriented Design in UML by Meilir Page-Jones

The Review

I really enjoyed reading this book and I think it’s one that I could come back and read again to gain something else from in the future.

Nearly all the mistakes that I’ve made and seen made with respect to the design of object oriented code are outlined in one form or the other in this book.

The book is split into three sections. The first discusses some fairly basic object oriented concepts, the second covers UML as a notation for describing our designs and the final section goes more deeply into the principles of object-oriented design.

What did I learn?

  • Although we don’t seem to use UML much these days I was coming to the conclusion while reading those chapters that perhaps UML is useful as a design tool but the aim shouldn’t be to come up with a UML diagram, but rather to drive a design in code.

    This is something which Uncle Bob also touched on recently:

    Is TDD a replacement for design?

    No. You still need all your design skills. You still need to know design principles, and design patterns. You should know UML. And, yes, you should create lightweight models of your proposed software designs.

    We actually found on a project I worked on recently that everyone had a different way of diagramming a design and it would have been useful to have a common notation between us. UML is surely the tool to solve that problem.

  • I quite like the way that Page-Jones describes the different types of messages that objects can receive:
    • Informative – a message telling an object about something that happened in the past.
    • Interrogative – a message asking an object to reveal something about itself.
    • Imperative – a message telling an object to take some action on itself.

    An interrogative message is effectively a getter whereas the other two are commands being sent to the object. I’ve not seen the distinction between events which happened in the past and those which are going to happen in the immediate future.

  • I’ve frequently come across the idea of information hiding when it comes to designing objects but Page-Jones introduces the idea of implementation hiding which I think is really neat.

    The idea is that while some information about our object will be viewable to other objects e.g. through attributes/getters, we can still hide the implementation of that information internally so that if we we want to change it in the future then we won’t have to change all its clients too.

  • I found the concept of the rings of operation really interesting. The idea is that there are some methods on our objects which just make use of other methods on the same object. Those methods wouldn’t touch any of the fields of an object directly but would rely on those methods in the inner rings to do so.

    For example if we have a getter on an object to access a field then if other methods on that object want to access that field they should go via the getter instead of accessing the field directly.

    I often find myself avoiding using getters with the hope that if don’t increase their usage then it will be easier to get rid of them in the future. This approach would discourage doing that.

  • I like the idea of type conformance when it comes to inheritance – we should try to ensure that any sub types adhere to the contract of their parent.

    The other part of this chapter describes ‘closed behaviour‘ – all the operations on any class that we inherit from should obey our class’ invariant.

    I think this can be where we go wrong when we write classes which extend a List for example. The API of a List will typically have ‘Add’ and ”Remove’ operations but on a lot of the application I work on we only want the ‘Add’ functionality and not the ‘Remove’ option. Page Jones suggests that if we want to use inheritance in this situation then we should override methods on the super class to make ‘Remove’ do nothing.

  • I now find that I prefer Page Jones definition of cohesion:

    Class cohesion is the measure of interrelatedness of the features (the attributes and operations) located in the external interface of a class

    I’m inclined to believe that we might be able to tell how related the features are by looking at the clients of the class and seeing whether they are all using the class in similar ways.

    He then outlines three signs that we have cohesion problems with a class:

    • Mixed instance cohesion – a class has some features that are undefined for some objects of the class. I find that this typically happens when we try to make a generic data type to cover everything and then try to jam any variations on the type into the same definition. It is typically solved by pulling out another class. This is the worst type of cohesion.
    • Mixed domain cohesion – a class contains an element that directly couples the class with another class that is unrelated domain wise. This typically happens when we mix infrastructure code into our domain code.
    • Mixed role cohesion – a class contains an element that couples it with an unrelated class in the same domain. I think this is the most typical type of cohesion that I’ve seen and the main problem is that we end up with classes which have multiple roles which makes them difficult to change.

In Summary

There’s way more in this book than I could ever hope to cover here but these are some of the interesting bits that stood out from this reading of it. I’m pretty sure that I’ll come back to this one in the future.

While reading the book I had the feeling that some of the ideas are quite similar to those in Domain Driven Design and since this book was published it contributes to my belief that a lot of DDD is covered by just doing OOP well.

Overall this is a really good book, worth reading.

Written by Mark Needham

December 1st, 2009 at 11:26 pm

Posted in Books

Tagged with ,

Zen Mind, Beginners Mind: Book Review

with 7 comments

The Book

Zen Mind, Beginner’s Mind by Shunryu Suzuki

The Review

I first came across the actual term beginner’s mind when reading through the ‘Wear The White Belt‘ chapter of Apprenticeship Patterns although it was often mentioned to me on one of the first projects I did at ThoughtWorks a couple of years ago that people liked teaching me things because I just took the information in pretty much without questioning.

I find nowadays that I analyse what people tell me way a lot more and then compare it against what I already know to see if it adds to my understanding. In a way this is useful but sometimes prevents me fully understanding ideas since I have already judged them.

I started researching beginner’s mind a bit to see if there was anything written on the state of mind required to maximise learning and this was the book that kept being mentioned so I decided to get a copy of it.

It is fundamentally a book on Zen and a lot of the stuff around that area didn’t make a lot of sense to me but I think there were some general ideas which can be applied to learning in general.

What did I learn?

  • One of the early chapters sets the message for the book with the following quote:

    In the beginner’s mind there are many possibilities. In the experts there are few.

    Straight away it gets to the point which I think describes the problem that we have in software development once we’ve done a few projects and accumulated a set of ideas of the best way to deliver software – we often stick to those ideas and aren’t open to the idea of better ideas being out there.

    On the other hand as Fred Brooks points out there is no silver bullet so perhaps this also explains why there is often skepticism when new ideas are described since its quite likely that potential negative points of these approaches have either not been described or not yet discovered.

  • The author raises some interesting ideas around how to get the best out of people by suggesting that the best way to do this is to let them do what they want but to watch them. Although he then went out to reference this back as a metaphor for controlling our own thoughts I was reminded of the Netflix culture slide show which I came across lately in terms of how they give employees freedom but expect them to act in the organisation’s best interest rather than expecting employees to follow a lot of rules.
  • One thing I really liked was the emphasis on listening to what someone says ‘without having your own idea [in mind]…forgot what you have in your mind and just listen to what he says’. I think one problem we can run into when listening to other people is that we extract the bits of what they say which fit in with what we believe – something known as the confirmation bias.

    I actually found an old post of mine which lists some mistakes we commonly make when listening to others speak. It makes quite interesting reading.

    Another quote from the book sums up a more useful approach:

    See things as they are, observe things as they are, let everything go as it goes

  • He goes on to suggest that we should have no negative or positive feelings towards what someone says to us and that we should give up our preconceived ideas and subjective opinions which I didn’t think made much sense in the software development game since a lot of what we do is about assessing the merits of different approaches.

    The beginner’s mind entry on the C2 wiki makes more sense by describing Ward Cunningham’s approach:

    You can generally tell when you’re dealing with someone who really knows their stuff by the amount of reference they make to the way it has always been done. Folk like our own WardCunningham seem able to ditch all that stuff and approach each problem as if it were completely new and they had never done anything like it before.

    Then, when they have a solution, they’ll either recognize it as a Pattern in the standard lexicon, and leverage readymade tools, or not. But they never come in armed for bear when all the customer needs to catch is clams.

    It seems like we only initially need to have an empty mind while we are taking in the new information and then we can make use of the knowledge that we already have later on.

  • The author suggests that ‘when you do something just to do it should be your purpose‘ which seems somewhat similar to the idea of focusing on the process in Agile instead of always on the outcome of what we’re doing.

    While a result focus can be helpful I often notice that important things like the quality of what we’re making get dropped by the wayside if we focus too much just on completion.

    I do think there is some need to focus on whether what we’re doing is actually improving us (although the book advises against this) and I recently came across Chad Fowler’s idea of always asking ‘Am I better than yesterday?‘.

  • It is pointed out then when learning zaizen we cannot expect rapid progress but instead that we will progress little by little which I think is pretty much the same in software development.

    With nearly all skills a lot of practice is needed – as Talent is Overrated points out – we don’t just become an overnight sensation but need to work our way through the Dreyfus Model for each skill gradually improving our level.

In Summary

Although this book is about Zen I still found some interesting ideas about learning and I guess its always interesting to read something a bit different.

I’d be interested in knowing if there was a book that covered beginner’s mind purely from a learning point of view instead of Zen if anyone knows of any titles!

Written by Mark Needham

August 12th, 2009 at 9:06 am

Posted in Books

Tagged with ,

Brownfield Application Development in .NET: Book Review

without comments

The Book

Brownfield Application Development in .NET by Kyle Baley and Donald Belcham

The Review

I asked to be sent this book to review by Manning as I was quite intrigued to see how well it would complement Michael Feather’s Working Effectively with Legacy Code, the other book I’m aware of which covers approaches to dealing with non green field applications.

What did I learn?

  • The authors provide a brief description of the two different approaches to unit testing – state based and behaviour based – I’m currently in favour of the latter approach and Martin Fowler has a well known article which covers pretty much anything you’d want to know about this topic area.
  • I really like the section of the book which talks about ‘Zero Defect Count’, whereby the highest priority should be to fix any defects that are found in work done previously rather than racing ahead onto the next new piece of functionality:

    Developers are geared towards driving to work on, and complete, new features and tasks. The result is that defect resolution subconsciously takes a back seat in a developer’s mind.

    I think this is quite difficult to achieve when the team is getting pressure to complete new features but then again it will take longer to fix defects if we leave them until later since we need to regain the context around them which is more fresh in our mind the earlier we fix them.

  • Another cool idea is that of time boxing efforts at fixing technical debt in the code base – that way we spend a certain amount of time fixing one area and when the time’s up we stop. I think this will work well as an approach as often when trying to fix code we can either get into the mindset of not fixing anything at all because it will take too long to do so or ending up shaving the yak in an attempt to fix a particularly problematic area of code.
  • I like the definition of abstraction that the authors give:

    From the perspective of object- oriented programming, it is the method in which we simplify a complex “thing”, like an object, a set of objects, or a set of services.

    I often end up over complicating code in an attempt to create ‘abstractions’ but by this definition I’m not really abstracting since I’m not simplifying but complicating! This seems like a useful definition to keep in mind when looking to make changes to code.

  • Maintainability of code is something which is seriously undervalued – I think it’s very important to write your code in such a way that the next person who works with it can actually understand what’s going on. The authors have a fantastic quote from Perl Best Practices:

    Always code as if the guy who ends up maintaining your code is a violent psychopath who knows where you live.

    Writing code that is easy for the next person to understand is much harder than I would expect it to be although on teams which pair programmed frequently I’ve found the code easier to understand. I recently read a blog post by Jaibeer Malik where he claims that it is harder to read code than to write code which I think is certainly true in some cases.

  • There is a discussion of some of the design patterns and whether or not we should explicitly call out their use in our code, the suggestion being that we should only do so if it makes our intent clearer.
  • While describing out how to refactor some code to loosen its dependencies it’s pointed out that when the responsibilities of a class are a bit fuzzy the name of the class will probably be quite fuzzy too – it seems like this would server as quite a useful indicator for refactoring code to the single responsibility principle. The authors also suggest trying not to append the suffix ‘Service’ to classes since it tends to be a very overloaded term and a lot of the time doesn’t add much value to our code.
  • It is constantly pointed out how important it is to do refactoring in small steps so that we don’t break the rest of our code and to allow us to get rapid feedback on whether the refactoring is actually working or not. This is something that we’ve practiced in coding dojos and Kent mentions it as being one of his tools when dealing with code – I’ve certainly found that the overall time is much less when doing small step refactorings than trying to do everything in one go.

    I’m quite interested in trying out an idea called ‘Bowling Scorecards‘ which my former colleague Bernardo Heynemann wrote about – the idea to have a card which has a certain number of squares, each square reprsenting a task that needs to be done. These are then crossed off as members of the team do them.

  • An interesting point which is made when talking about how to refactor data access code is to try and make sure that we are getting all the data from a single entry point – this is something which I noticed on a recent project where we were cluttering the controller with two calls to different repositories to retrieve some data when it probably could have been encapsulated into a single call.
  • Although they are talking specifically about poor encapsulation in data access layers, I think the following section about this applies to anywhere in our code base where we expose the inner workings of classes by failing to encapsulate properly:

    Poor encapsulation will lead to the code changes requiring what is known as the Shotgun Effect. Instead of being able to make one change, the code will require you to make changes in a number of scattered places, similar to how the pellets of a shotgun hit a target. The cost of performing this type of change quickly becomes prohibitive and you will see developers pushing to not have to make changes where this will occur.

  • The creation of an anti corruption layer to shield us from 3rd party dependency changes is suggested and I think this is absolutely vital otherwise whenever there is a change in the 3rd party code our code breaks all over the place. The authors also adeptly point out:

    The reality is that when you rely on another company’s web service, you are ultimately at their mercy. It’s the nature of third-party dependencies. You don’t have control over them.

    Even if we do recognise that we are completely reliant on a 3rd party service for our model I think there is still a need for an anti corruption layer even if it is very thin to protect us from changes.

    The authors also describe run time and compile time 3rd party dependencies – I think it’s preferable if we can have compile time dependencies since this gives us much quicker feedback and this is an approach we used on a recent project I worked on by making use of generated classes to interact with a SOAP service rather than using WCF message attributes which only provided us feedback at runtime.

In Summary

This book starts off with the very basics of any software development project covering things such as version control, continuous integration servers, automated testing and so on but it gets into some quite interesting areas later on which I think are applicable to any project and not necessarily just ‘brownfield’ ones.

There is a lot of useful advice about making use of abstractions to protect the code against change both from internal and external dependencies and I particularly like the fact that the are code examples showing the progression of the code through each of the refactoring ideas suggested by the authors.

Definitely worth reading although if you’ve been working on any type of agile projects then you’re probably better off skim reading the first half of the book but paying more attention to the second half.

Written by Mark Needham

July 6th, 2009 at 12:43 am

Posted in Books

Tagged with , ,