you are here: Home Authors Joel Tosi

Constant focus on quality and code health is critical for the long term viability and maintainability of software.  This focus on quality is a trademark of agile teams but you don't have to be 'doing the Agile' to focus on quality. Regardless of how you develop software, testing and in particular unit testing are an important tool to have in your toolbox.  Given the importance of unit level testing, why do so many companies struggle with unit testing and its adoption? When unit level testing is non-existent or inconsistent, the reasons fall into two main categories:

  • General misunderstanding on what a unit test provides
  • Developers aren't good / shy away from testing as it is out of their comfort zone

There is a third reason, more like a myth, that is very popular - the myth that 'we don't have time to test'.  This is false - nothing will slow you down more than writing as much code as you can without some way of constantly being able to verify you haven't broken your assumptions of the intent of the code.  We tend to hear this myth coming mostly from developers.  This comment is usually rooted in a blend of the two primary reasons with the majority of the cause coming from developers simply shying away from testing.!StumbleUpon!

Agile practices may seem easier for small, isolated teams but what happens in the real world when applications go across teams and dependencies rear their ugly head?  The answer I hear too often is 'adjust in your planning sessions so that the dependencies go away.'  That's not a real, complete solution to me.  Here is why - that answer makes sense if we are creating an application and we have two stories - Add item to shopping cart and Remove item from shopping cart for example.  In this case its logical to plan accordingly.  We wouldn't want to release the product without being able to add items and additionally this functionality seems in control by the team.

What about this more common example though - a front end team develops an application that depends on data from a data team.  On top of that, not only does the front end team depend on the data team, but so do 3 other teams, all with different priorities and needs.  And since it is the real world, we have a deadline to hit - the application needs to launch in 6 weeks and the data team won't be able to finalize the data for the front end team for 4 weeks.  It doesn't make sense for the front end team to not work, especially if the amount of time they need is greater than the remaining two weeks.  What do you do?!StumbleUpon!

You are a responsible developer, practicing TDD and keeping your code clean through refactoring.  Your 'bar' is always green, but are you living and developing in a world of 'False Green'?  Is your green bar continuous or is it only measured at points in time - when you run your tests for example.  At the Lean Conference in April, Joshua Kerievsky gave an excellent presentation titled 'The Limited Red Society.' A summary of this presentation can be found on Joshua's site here and the video can be found here. Synopsis: we need to be aware of the state of our code at all times, not just when we run our tests.  In the real world, things may break at non-ideal times, like during the middle of a refactoring, and we must fix them. Joshua's session really hit home about a month ago when I felt like I was refactoring with fire.

To set the stage, I was working solo on some custom code for a customer.  I developed it test-driven and had solid tests.  After I delivered the code to the customer, I saw a great spot for refactoring and simplifying the code so I dove in.  Then the customer came back with a change...but I was in the middle of refactoring! The change would only take me about 10 minutes but the refactoring session would last another hour or two to get to the point where I wanted it.  Right then I felt like I was refactoring with fire.  This was only a 10 minute change but a production emergency could go on quite a bit longer and I would be leaving my codebase unstable. I vowed to not let that happen again.!StumbleUpon!

You're going Agile and you couldn't be more excited.  You've read about all of the benefits and want that for your organization and you want it now.  Slow it down a little bit Buddy; realize that not only will Agile change the way you work, it will possibly require organizational and cultural changes.  Your organization only has a certain amount of change it can consume successfully in any given period - you only have so much transitional velocity.

One of my partners in crime at VersionOne, Mike DePaoli, has started a series of posts regarding using Agile to scale Agile.  I couldn't agree more with the thread and chatted with Mike briefly about adding a topic I spoke about at Agilepalooza - the idea of transitional velocity.  We know what velocity is in terms of Agile - the rate at which a team is delivering value, usually measured in average points per sprint or iteration.  Transitional velocity is how much change we can successfully introduce and make sustainable in a given timeframe.!StumbleUpon!

Regardless of the methodology you practice, continually improving should be your goal.  We want the product to be better, we want better quality, we want to work more effectively.  Agile, and retrospectives in particular, are effective in helping us improve because of the tight feedback loops and team ownership. How are we doing outside the team though?  Does your company have strange rituals that no one understands and no one can seem to change?  Do you have organizational OCD?  Say for example...

A team wants to deploy their software to another environment for testing...but they have to fill out a form and wait for a DBA to execute the SQL script to update the database.  That person executes the script and walk away, leaving the team to flail with questions. 'Did all of the data update? I don't know, I can't see it.'!StumbleUpon!

Finding the right amount of detail and decomposition with stories takes agile teams a few iterations, possibly releases, to get comfortable with.  It is a tough balance - we want the stories to be large enoughBut is it Jeff Patton? that our product owner(s) understands what the story is for and the team understands the story contextually, yet we need the work small enough so that we can have confidence in estimating and so that we can get the story flowing through our feedback loop soon.  I want to outline briefly how I like to approach this in the hope that it may help some others.

Jeff Patton is one of my favorite people, an overall awesome dude, and his storymapping is such a beautiful tool that I wish more tools would naturally support it.  When I am working with companies, I use storymapping as means of helping people not only visualize their product but also as means of helping groups understand where and when to break down work.  If you haven't heard or used storymapping before, please do check out Jeff's blog posting on it.  Its ok, I will wait.!StumbleUpon!

Its a little known fact that google was built by 3 staplers, a set of paperclips, and a couple of 2 by 4s.  Yep, some smart dude with a great idea had someone look at his product and that person replied, 'We can do this.  We just need about 4 dev resources and a few qa resources.'The stapler is off to the side

As ridiculous as this sounds, we still see it regularly in software development.  Not only is it amazingly demeaning to call people 'resources,' it also leads to other fallacies, such as:!StumbleUpon!

One of the most potentially dangerous states for a company to be in is where it is successful in spite of itself.  Companies that are (or once were) monopolies have a surplus of cash and little to no competition.  There is arguably little reason for them to change.  Is it possible for a company in this position to care enough about efficiency to adopt agile practices?  Historical success can cause a fear of change - if we try something else we might fail and we are fine now. Not only is this avoidance of change unhealthy culturally, the inability to seek improvement will eventually lead to drop in market position of the company. 

The past few years have seen the adoption of Agile practices in larger and larger organizations.  At last years Agile conference, Alistair Cockburn presented a keynote around the growth and spread of Agile.  One of the cornerstones of adoption is a healthy and desired feedback loop.  What can we do at organizations where competition isn't an immediate concern?  How can you address a space with a low appetite for change?  Is change possible without motivation?

We live in a time where not only can success happen quickly, but failure can happen even quicker. Beyond that, failure can happen cheaply. That fact should be a concern to market-leading organizations and  a prime motivator.  Cheap failure is equivalent to efficient, fast learning.  Your organization might be enjoying a comfortable revenue position now, and perhaps the cost of entry to your market is high - but the idea / company that becomes your largest challenger does not need to come at you from a replacement angle.  The company that challenges a financial exchange does not have to offer all of the same trading properties or strategies.  The challenger to an online auction site might not even come from commerce but from a communication channel that then makes transactions simpler and in more confidence.

Can change happen without motivation?  No. If you are having difficulty finding motivation, then look no further than the startups of the past few years along with the current boom of startups happening now.  The best of these startups are learning all market aspects very cheaply and adapting quickly.   Let this start your motivation for seeking continuous improvement and never being satisfied.  If this doesn't motivate you - just wait... someone with less to lose will help motivate you by making you lose a whole lot more.!StumbleUpon!

I've said it myself before - this software needs to be designed properly; You know, foundation of a house, and such.  Once the design is solid, oh just trust me, we will create some software real fast.  And then we went off to ponder and pontificate, and create documents showing how elegant this solution would be.  We used and diagrammed all of the proper patterns, creating interfaces and abstractions along the way.

We wrote code; tons of code.  We deviated as we learned more of the system, as time became tighter, and so on.  Once the project was released, 'Someone should really update that design document'...and no one does.

Its common, it happens.  I've done it.  But this isn't about the benefits of emergent design, lets look at the common idiom of our software being a house.

Would you want the real version of the house based on the software you build?  Would you want your contractor to agree to a set of prints up front, but once you move in realize that the only way to turn on the lights was to flush the toilet?  How about that study you wanted?  Would you be happy if your carpenter decided that you, 'the user', wouldn't need a study?  Would you feel better if afterwards, the architect came back and updated your blueprints?

4,192,876,492 - that is my estimate of the number of unneeded interfaces in code out in the wild right now.  Would you want that many light switches in your house, you know, in case you wanted to switch something else on besides the ceiling light?

Houses can have blueprints because they are based upon static principles with high commit costs.  A foundation is made of concrete.  You can change it but it will cost substantially and can create structural risk.  Software is malleable and code is not concrete.  We should be exploiting that benefit instead of trying to move towards a less flexible model.

Lets take this a step further.  Houses are built upon civil engineering principles - stress loads of materials, heat dispersion, pressurized values of systems.  For example, the beams supporting your walls are probably slightly over 14 inches apart.   That is not because that was a good number to go with.  That is because we know, through testing, that the stress load we can expect a wall 2 by 4 to support is actually 24 inches on center but because of the varying in woods (drying, species), most carpenters build at 16 inches on center.

What would be similar in concept to this?  Programming languages, platforms, maybe containers or frameworks.  We know how languages function in certain applications and situations; what platforms work best for certain targets; what containers will provide for us.  Even these can be changed - swapping containers shouldn't be painful.  These items are addressable upfront.

Finally, have you ever heard of a civil engineer say 'concrete isn't good enough for this common residential house, I am going to invent something new.'?  You don't, it would be ridiculous, overly costly, and people could die.  But in software, too often we design and say something similarly absurd. 'We need a custom web server, Apache wouldn't scale for our special problem'.  That statement is as ridiculous as trying to make your own concrete.


Some people much wiser than me have made comments such as 'The cost of version 3 of software is exponentially greater than version 2' and '

Think about that.  We may never see a 'version 3' of ebay or amazon. And maybe we don't need to.  The cost of such an endeavor, to replicate what those applications are providing, would not be trivial and the return on such an investment may very well never be realized. 

In enterprise software development, we see plenty of high version numbers.  Some of this is valid - we learn more about our customers and we create solutions to help solve their problems.  If we can say 'Here is how this functionality helps save me time / solve a problem' - then the software could be worth writing.  If instead it is 'It would be cool if the software did this' or the famous 'we need to re-architect the solution' - then we should take a hard look in the mirror.  How many applications out there have some AJAX functionality just for the glamor of it?

Software development is a sunk cost.  Understand that and accept it.  While I am not trying to put people out of work, understand that at some point your software is as complete as it needs to be.  Instead of allowing people to work collaboratively on solving the next problem, too often we create work to keep people employed (more to come on 'Resource Planning').  The changes requested for this software don't create any large tangible benefits, but it will keep the delivery team busy for a few months.  Its ok to not have delivery teams trying to deliver all the time.  Its actually probably cheaper.

Please don't focus on keeping people busy to keep them busy.  Instead focus on having your teams research and understand what your consumer wants and deliver upon that. Not only will you end up with a better offering and a competitive advantage, you will find that you now have a staff of highly engaged people solving problems and not just going through the motions.!StumbleUpon!

I was recently asked to do a prototype for migrating some, well, lets say not very recent user interfaces to a more web based view on them. The first test was to just make sure that a web based application could perform fast enough and we didn't need to go swing. For the record, I'm not a swing fan because of all the layout finagling and I sure don't like GWT doing all my work for me. Call me a purist or an idiot, your call.

I check out what the users want and come up with a nice thin app using JQuery on the front end communicating via REST services responding with JSON for the datasets. Pretty standard stuff. Nothing too revolutionary there. If you're not using REST, I'd recommend it but I can get on that soapbox later. What was interesting was the request that these workers prefer to use keyboard shortcuts. In essence, I was asked to make a web based application that didn't use a mouse. Pretty interesting and different than usual.

I toss together this prototype and demo it - first suggestion was could I make it so there was just a text box interface where users could type in shortcuts and then use key combinations to drive functionality.

The solution I ended up with uses the hotkeys plugin for jQuery -
It is crazy easy to use, here is binding the f4 key to execute whatever is typed in the text window:

$(document).bind('keydown', 'f4', function(){ executeCLI();});

function executeCLI()
var cliString = $("#prs_cli").val().trim();

//Process cliString, call more functions, etc

Its crazy simple to bind functions then to key combinations. You can even bind key combinations, i.e.

$(document).bind('keydown', 'ctrl+c', function(){ executeCopy();});

Why would anyone do this? At first I asked the same question. The mouse is there, use it. But then I started using the CLI interface for the web. Think about how faster you, the maven, are with CLI? Think about the experienced user being able to interact with web apps this way. Pretty cool and effective stuff.

So check out hotkeys and maybe think about some CLIs for your super users of your web apps.!StumbleUpon!

To the contrary of my previous post, I thought I would say what we do know. Without further ado, What we do know (an abbreviated list...well, hopefully)

  • We know that its hard to keep an architecture simple
  • We know that if you have a solution or tool in place that has a 'large impact for replacement' - boy oh boy, did you either eff up the use of the tool or did you purchase one sh1tburger of a tool to start with
  • We know that if you want your employees / team / co-workers to be engaged and highly productive, you have to allow them to be engaged and highly productive.

Perhaps I will dive into this in more detail in future posts.!StumbleUpon!

You know those conversations you have in your head that always come across sounding so awesome? Well, here is the start of one that I had in my head a few months back, and a conversation that I wanted to have but you know, at the time it might have been career limiting.

Command-and-control-director: 'You don't know my world. I've worked for 10 years to make my world just right, you can't change it. You don't know the implications of the changes you are suggesting and how it would impact the company.'

Me: 'You're absolutely right. I have no idea of the implications. And on top of that, I have no desire to know or even hear the implications.'

By no means do I claim that this is an original thought - sometimes it is prior knowledge that blinds us from seeing and understanding other opportunities. Once my daughter wanted to take off her shoes and socks and go stand on some wet rocks in this rock pond at an arboretum. It was 50 degrees out and breezy so I tried to convince her otherwise. But she was persistent and I let her. She loved it, she played in there happily skipping around for 30 minutes.

The pond water was heated.!StumbleUpon!