Tag Archives: software development

Agile, Lean and Software Book Sale

I have a number of hard copy books for sale.  They are great books and I would keep them.  However I want less clutter in my life and will switch to electronic format for ease of storage and usability (for me).

Some still want the old style and these books are still valuable.  They are in excellent condition and should expect to receive a decent second hand price.  I’ve not listed a price along side the books but you can use your own detective skills to make a decent and respectful offer. For those living in Perth, Western Australia I’m happy to drop off the book personally.  For others postage will be an extra cost.  Email me at n_zdunic AT yahoo DOT com DOT au to make an offer.

As the items are sold I will put a strike through the item.

Book List

Domain Driven Design – Eric Evans

Refactoring – Martin Fowler

Peopleware – Tom DeMarco and Tim Lister

Code Complete – Steve McConnell

Rapid Development – Steve McConnell

Test Driven Development – Kent Beck

Writing Effective Use Cases – Alistair Cockburn

Agile Software Development – Robert C. Martin

Software Architecture – Len Bass et al

Applying Domain-Driven Design and Patterns with Examples in C# and .NET – Jimmy Nilsson

Analysis Models-Reusable Object Models – Martin Fowler

Pattern-Oriented Software Architecture Vol 1 – Buschmann et al

Project Retrospectives – Norm Kerth

The Secrets of Consulting – Gerald M. Weinberg

Death March – Edward Yourdon

Agile Project Management 1st Edition – Jim Highsmith

User Stories Applied – Mike Cohn

Extreme Programming Explained 1st Edition – Kent Beck

Extreme Programming Explained 2nd Edition – Kent Beck with Cynthia Andres

The Pragmatic Programmer – Andrew Hunt & David Thomas

Coaching Agile Teams – Lyssa Adkins

Enterprise Integration Patterns – Gregor Hohpe & Bobby Woolf

Patterns of Enterprise Application Architecture – Martin Fowler

Refactoring to Patterns – Joshua Kerievsky

Scaling Software Agility – Dean Leffingwell

Writing Solid Code – Steve Maguire

Debugging the Development Process – Steve Maguire

The Mythical Man Month – 20th Anniversary Edition – Fred Brooks

Surviving Object-Oriented Projects – Alistair Cockburn

UML Distilled Second Edition – Martin Fowler

Dynamics of Software Development – Jim McCarthy

Object-Oriented Software Construction – Bertrand Meyer

Continuous Delivery – Jez Humble and David Farley


Software Methodology Tussles Concluded

In computing’s earlier days some 25 to 40 years ago we had a big tussle on for software development methodologies. In 1993, I and another Honours Student wrote about some research we conducted to catalogue just some of them, and yes there were a lot, and we produced this paper in all its student glory (part 1 and part 2).  I don’t have the electronic version anymore, rather the scanned copy which I somehow manged to divide into two sections during the scanning process i.e. paper jam.

We started with methodologies that were somewhat driven by the technology at the time.  For example procedural based languages created a number of Structured System Analysis models like Edward Yourdon’s (Modern Structured Analysis) also covered by Meilor Page-Jones’s famous book Structured Systems Design.  Information Engineering was somewhat data driven and made one of its originators a lot of money that he was able to live it up on a Carribean Island for the rest of his days.  Some, fortuntately did emphasis the people side of things.  The paper acknowledges this as generations of methods emerged.

This is where we have got to today.  People still create software and usage of ‘guides’ like Scrum, Kanban and some hybrids specifying varying levels of details recognise this.  Various prescriptions work in different contexts and our job as developers of solutions is to apply the right methods.

Furthermore the prescriptions I’ve seen attempted over the last 20 years have all been, to put it bluntly, been terrible.  Rational Rose’s Object Oriented View of the World was an improvement but still smelt of documentation beauty rather than delivering real customer value.  Consulting firms tried to market their methods and created massive tombs of unreadable text that no one bothered with anyway.  I remember reading in 2003 DMR’s (now Fujitsu Consulting) massive metholodolgy – they must have been thinking that execution word for word would produce the system everyone wanted.  It never happened quite the way the authors expected.  Prince2 is a repackaged variant of documentation heavy methodology which seems to be implemented by automatons keen on producing wonderfully thick documents with idiosyncratic diagrams and prose of the authors own concoction and no one else’s that should be filed in fiction in the library.  I’m not sure the claims that Prince2 can coexist in an Agile environment, the way I saw it implemented says no.  It could’ve have been that they didn’t understand that cross functional teams, a backlog, a willingness to create working software early and regularly and to break dependencies is critical to it’s success (credit to Mike Cottemeyer to making this stark).

Agile is certainly an improvement, but as we learn more about human interactions we can expect more improvements in the coming years. As for a tussle, it’s still a tussle given the way I observe the interchanges amongst Scrum, Kanban and the various scaling approaches.

Slack by Tom DeMarco

I just finished reading Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency by noted author Tom DeMarco, famous for Peopleware (with Tim Lister) and Waltzing With Bears and for those who go back further author in the 1970s on Structured Systems Analysis and Design.

It really did strike a chord with me and I dare say with similar veterans of the software development field.  DeMarco has been writing about people side of software development work since the 1980s, however as respected as he is my experience indicates that not much of his learned writings have hit home with the software project community.

The overall premise of the book is to ironically and paradoxically juxtapose efficiency and effectiveness by inserting the variable of slack.  With slack the organisation can position itself to be more effective which in turn means turning down the efficiency dial.  The question is what does one what value more effectiveness, how much we delight our customers, and efficiency – how well we do are jobs (eliminating the customer in this definition).   The answer is hopefully effectiveness.

What is slack?  In short it’s the small amount of time we spend not directly generating customer value but learning how we increase customer value long term, that is short term vs long term gains.    Perhaps the best known example that Google incorporates Slack into their work week.  They are famous for the 20% budget for the week for employees to work on their own pet projects.  This has spurned many useful products that we take for granted today.  That is they budget for innovation.

Google’s example is perhaps the most famous example of slack we know of today but there are other forms of slack that we use to keep the organisation healthy and people working in those organisations healthy which for me is the most resonate element of the book.  Tom covers alot of other elements which are very important as well but they all come back to the idea of healthiness.

Without this this ‘health’ as I like to call it, it becomes difficult to work effectively and grow. DeMarco notes Slack – ‘It is the lubricant of change. Good companies excel in the creative use of slack. And bad ones can only obsess about removing it.’  Thereby removal of slack, that is the aim of 100% utilization, invariably consigns a company into morbidity and perhaps even death and the accompanying distresses that entails.

The book is as much a catalogue of fallacies, some of which we already know about but are fearful to deal with.  Tom does provide some guidance here and in some cases advises best be looking for a new job in others.  Some fallacies and maladies:

  • People under pressure do not think faster – from Tim Lister.  Pressure has limited capcity to reduce delivery time – 10 to 15%
  • Do more work and more we get done – but we don’t think about context switching. Lean Principles tell us that doing less increases throughput.  That is limit work in progress.
  • Overtime – causes reduced quality, burnout (and poor health), staff turnover, zombie workers.  Ineffective long meetings or meetings with no basis are the main culprit
  • Creative Time Accounting – spending 12 hours at work only recording 8.  I witnessed a guy regularly do this but I do credit him for negotiating a longer holiday afterwards – but I see this as a reverse gaming of the system as well.  Maybe still recovering from that.
  • Cutting useful support staff when there is a downturn.  That’s a great opportunity to innovate!  Furthermore support staff do the little things like printing and binding.  Expensive thought workers should not to do this, generally speaking.
  • Replacing cut stuff with yourself (being the manager) – now all your slack is gone and your team attending to team health and innovating activities is lost.  You’ll look busy and be commended for it, perhaps, but take a look at the bigger picture.
  • Unsafe to fail – using your power to instill fear and therefore limiting the revelation of new information and learning opportunities
  • Applying Process thinking to Knowledge Work – a great example from 1980’s Volvo using a single team to build a complete car.  Here the team decides how to do its work.  Empowerment has wondrous effects on people!
  • Lip service paid to quality and when it is used it’s the quality program to stifle and frustrate rather than assist
  • Management By Objectives is still alive e.g. sales selling to quota over time diminishes customer satisfaction.  This is aligned with the idea of local optimization.  Sales is doing well but oblivious to the health of the entire company.  But we mustn’t blame them people, the System caused this.
  • Lack of robust Vision – content free baloney as James Shore puts it.  A vision needs to motivate – resonate through truth and excite the future
  • Leadership – it comes from all and not just the anointed few
  • When change occurs it is done inhumanely.  People are expected to learn a new way and then perform at the same rate as before.  The Satir change model graphically illustrates that this doesn’t occur.  Kanban (David Anderson) hopefully to the rescue here with change more gradual and respectful to people’s current roles and responsibility and evolution into new roles.

Those are the main takeaways from the book.  I enjoyed it and must get and revise Peopleware again.  It’s been a while.