• About

Software For Profit

~ How to Build Incredible Software

Software For Profit

Monthly Archives: January 2013

The Sardine Revolution – Unit Testing And The New Software Development

13 Sunday Jan 2013

Posted by Kyle in Technique

≈ Leave a comment

Tags

agile, Continuous Delivery, Modularity, OOD, OOP, Software Craftsmanship, TDD, Test First, Unit Test

“Every revolution was first a thought in one man’s mind”
Ralph Waldo Emerson

A number of years ago I remember going to youth group with a friend of mine and playing this super-fun game called “Sardines”.  The rules were basically:  one person sardinehides – then everyone searches and whoever finds the hider hides alongside them until everyone (except for one person) is hiding at which time the lonely soul that is still searching is declared the “loser”.

The reason I bring it up – is because this game reminds me a lot of something that is happening in the software world.  A subtle revolution has been taking place – and almost everyone who finds out about it quietly joins in and hides alongside the rest of the group that is “in-the-know”.

Now not everyone so quietly sits down and joins the can of sardines – every once in a while, like the kid who just couldn’t bear his friends becoming the loser, someone speaks out and gives away the group’s hiding place.

One of the most recent and best articulations of this revolution is from Steve Freeman and Nat Pryce – their expression is so compelling that even if they just stopped with the title of their 2010 book they would have pushed our industry forward several big steps – “Growing Object-Oriented Software, Guided by Tests“.

Ok – let’s stop and absorb that.

There has been a lot of talk about Test Driven Development and Writing Tests First – and these are both good and important ideas.  But they are more like things we feel like we need to bolt on to our technique as an optional upgrade.  In reality – the entirety of our engineering technique needs to be based on using testing as a guide.

But Why?

Guiding your development with testing buys two major advantages – confidence as you make changes to code as well as enhanced modularity and conceptual integrity.

Modularity is a very important ingredient in having an effective agile process.  Monolithic software breaks agile processes as it leads to difficult planning and engineers stepping on each others’ toes during development – having an effective agile process through enhanced modularity means faster (and more fun) delivery.

Modularity is also very important in releasing as frequently as possible (see Continuous Delivery – by Humble and Farley).  An optimized delivery pipeline means getting software in front of users quickly and frequently – which means more *actually useful* feedback.  This means more value to customers faster.

Ok!  How do I join in the fun?

There are several major things that you can do:

1) Read!  Start with the Freeman and Pryce book listed above – then hit Google.  There is a lot of material available about the specifics of writing unit tests.

2) Find a Mentor!  Unit Testing is an art – if you can find a mentor who knows about it and practices it regularly you will put yourself on the fast track.

3) Don’t disengage your brain!  Always question every practice – to make sure that you are understanding it for yourself.  When it comes to “doing unit tests right” – do not take the word of your mentor, a website, or even your own mother – think for yourself.

4) Keep following this blog!  We will follow up shortly with a very in-the-code and specific expose into the writing of a unit test.

But how do I sell this?

We programmers don’t like to be the Traveling Salesman – because we know it’s a difficult problem to start with (NP-Hard actually).  But the pragmatists among us realize that our Salesmancolleagues, our boss and probably others get grumpy if they think we are spending time on things that aren’t bringing value to the organization.

Fortunately that is not the case in our situation – code that is guided by good testing practices is easier to read as well as easier and less risky to change.  Selling this to people who haven’t been directly involved in this practice should be as easy as a short (though non-trivial) proof of concept effort.

The one thing to remember if you do need to convince others within your organization – as with any tool or technique there will be a learning curve for every individual that hasn’t had experience with it before.  This should not be viewed as a problem with a tool – but just a natural part of growing the skill level of the team.  Every organization expects its members to be continually enhancing their own abilities while balancing the demands of accomplishing short-term objectives.

Next Steps

All you have to do is get started. Be creative of course – if you’re new to testing and you don’t want to try it at work until you are more comfortable with it maybe practice a little after-hours or on your breaks first.

Making this shift – to guiding your development with testing – will make your software even more incredible.

Recent Posts

  • Killing Software Development Capacity, Part 3: Superficial Thinking
  • Killing Software Development Capacity, Part 2: Philosophizing
  • How To Use Systems Thinking To Destroy Your Team
  • The Text-Native Communicator, Remote Work & Serendipity
  • Silos Are A Good Thing ™

Archives

  • February 2020
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • June 2019
  • May 2019
  • April 2019
  • December 2018
  • August 2018
  • July 2018
  • June 2017
  • May 2017
  • February 2017
  • January 2016
  • November 2015
  • June 2014
  • October 2013
  • January 2013
  • September 2012
  • August 2012

Categories

  • agile
  • General
  • Management
  • Philosophy
  • Scala
  • SOLID
  • TDD
  • Technique
  • Uncategorized

Meta

  • Register
  • Log in
  • Entries feed
  • Comments feed
  • WordPress.com

Create a free website or blog at WordPress.com.

Cancel
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy