Archive for February, 2007

Compassion as a core programming virtue

February 25, 2007

James Dobson says “Compassion is a central theme of the work my company does.” Maybe he’s right and we should add compassion to those three fundamental virtues of a programmer. I’m going to quote the full text from the Netropolis, in turn quoting Randal Schwarz:

  • “LAZINESS: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer.
  • IMPATIENCE: The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least that pretend to. Hence, the second great virtue of a programmer.
  • HUBRIS: Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about. Hence, the third great virtue of a programmer.”

In this context we could define:

  • COMPASSION: What you feel when you want your team to work better together, and not let your fellow software developers suffer the pain of poor quality software development

It’s the Emotional Intelligence in the programmer virtues. When you start thinking of the way you work with others to deliver software, the other virtues kick in. Given that we are lazy, we want to deliver software features as quickly as possible with the minimum amount of work. We are impatient to deliver great software and move on to the next business feature without all that re-work in between. We have hubris about how we work together as a team: not just our software development process, or the tools that enable it, but our culture too.

Technorati Tags: , , , , ,

Advertisements

Theory and practice

February 25, 2007

James Dobson has a good post on compassion in agile transformations. Here was my comment.

Maybe it’s the humanist in me (and I mean w-a-y down inside and hard to find in me) that makes me agree that much of religion is not about high-faluting theory, but simple practice. Preaching agile to the masses can be fun, but we often forget that what people are doing right now works for them:

  • Waterfall works for the management dogmas in place right now (e.g. cost accounting)
  • Process-oriented project management (e.g. Prince 2) is a lot more effective than doing no management.
  • Focusing on local maxima like developer utilisation, or lines-of-code (excuse me while I clean my mouth out with soap) works for cost accounting driven management
  • Writing detailed plans 3 or 6 or 12 months in advance can be a lot more useful than not thinking about the future at all

I think to change a company you need to both change some of these cultural axioms and some of the behaviours, such as moving from measuring cost to measuring throughput and cost. When you do that, you need to give everyone in the organisation the props to do the job and to continually help them in doing it. For example, showing them how to simplify down to stories, story points and velocity (software development throughput), and showing them how much more enjoyable coding is when we do that.

It’s hard graft and it’s satisfying graft.

Technorati Tags: , , , ,

Mac unit testing: how to get started

February 24, 2007

I wanted to write a post on Mac unit testing. I have been making my first attempts to do some test driven development, and have found a bunch of great resources. Some are very specific to the environment I’m using (coding Objective C and Cocoa on Mac OS 10.4 with Xcode 2.3) and some are general unit testing and other testing resources. I’m curious how these resources apply to both older and new versions (e.g. do these all work the same on Leopard or Xcode 3.0?), but I’m also commenting on how some older resources work in the new versions. For instance, you’ll find a good number of testing resources that refer to a time when OCUnit was not bundled with Xcode.

Unit testing on CocoaDev is a great place to start. It notes that OCUnit is now shipping with Mac OS 10.4 and Xcode 2.1. From a number of online reviews UnitKit seemed like the main competitor for OCUnit (and definitely has a better name). However, with the bundling of OCUnit, its creator Duncan Davidson decided to extend it further only by sending in patches to OCUnit. So once, you’ve decided on OCUnit, how do you use it?

There are one or two good introductions to OCUnit and one great one. Note that if you are using Xcode 2.3, the steps to ensure OCUnit is working in your project are basically the same (add a new target, add in the framework and create a new group for the test cases), except that your test target will be type “Cocoa > Unit Test Bundle” not “”Cocoa > Test Framework“”. Similarly, when you are creating a test case, the file that you add will be of will be of type “Cocoa > Objective-C test case class” not “ ”Cocoa > Objective-C SenTestCase subclass“. A lot of the links on this page you’ll find on the references and further reading section of Sen:te’s OCUnit page. Little known fact: Sen:te comes from a Go-term roughly meaning getting one step ahead. (and more obviously, adding the initials of the term to do the word itself gives you a bunch of functions with ”teST“ in them.)

All of these intros take a (perfectly well coded and working) app that exists already and add some tests on top. What would have made these intros better is to have taken a real test driven development approach: write the tests first and the code then the app around them.

A great general introduction to xUnit best practices is xUnit Patterns. It seems pretty exhaustive and I’ve found a few hours of good browsing there. It’s pretty early days for me but I’m enjoying reading a section (or two … or three) and trying out the principles in Xcode and OCUnit.

Technorati Tags: , , , , ,

To unit test or not to unit test?

February 24, 2007

Unit testing is just obviously the right thing to do, right? Not everyone agrees. Since at least one who does not actually cuts an awful lot of great code, he is well worth listening to. After all, it’s all about the code. I don’t actually write programs for a living (any more), so hats off to those who do. The inimitable Wil Shipley writes that Unit Testing ‘teh suck’ (between you and me, I’m still not really sure what this means above ‘sucks bigtime’). In the ensuing flamewar which can be read in the comments, there are some excellent points, e.g.:

• Unit testing gives you massive ROI. The earlier you test in your development lifecycle, the less you build on buggy code and the less you rework you need to do.
• Unit tests are less necessary for genius coders. If you are truly brilliant and write flawless code, unit tests are an overhead. The reality is that most of us are not this, even when we think we are.
• For a single app that is written once from scratch, which does not re-use code and which will not be re-used, and which will never have later patches or versions, unit testing does not add much value. For everything else, every time you write code without a unit test, you are building up a debt. That debt will need to be paid off with regression testing. At some point in the not so far future, those payments are going to be crippling you so much that it’s almost impossible to code. NOTE: this does not mean you have to unit test it, but you will have it test it. Wi’s alternative is that you a) try your very best to break your app and b) get it into a beta program with real users.
• It’s easier to code unit tests for some types of app that it is others. GUI code can be very tough to add unit tests for, unless you use a model-view-controller model, or more generally, ensure that UI is a very light wrapper. The best test of the usability and usefulness of a GUI is some tough, try to crash it in any way you can, beta testing. There are GUI testers out there, but YMMV.
• Just doing unit testing is not enough, you have to do it right. Ken Anderson wrote “I find that a number of programmers who think following the unit test mantra is the ”Right Thing“ are mislead [sic] and write freakin dumb unit tests. It is not worthwhile to write a unit test for something that will be absolutely obvious when running the application (does this button actually call this method when I click it – kind of like, if I stick this pencil in my ear, will it hurt?). Unit tests should be used for more complex tests that are difficult to verify easily, like, does the result of this complex calculation match the known good quantities I’ve calculated outside the application environment.”

Bill Bumgarner wrote a response to Wil, which shows how, for infrastructure code, unit testing has gone from being fad through a hype into a day-in-day-out technique of many great teams. He explains how Apple’s Core Data could not and would not have been finished without a lot more time or a lot more coders than they had.

Technorati Tags: , ,

Amie Street

February 11, 2007

I have just discovered Amie Street to download good music, and spent the last few hours browsing (interspersed with a little coding).

It is like iTunes in that you buy per song or per album, except the price ranges from $0-$0.98 per song depending on how popular the music is. If it’s new and there are no downloads, it’s free. If it’s downloaded a lot, the music becomes more expensive. Artists get 70% of sales. There is plenty of good free music and lots of good pretty cheap music too. With each $ you spend, you get a ‘rec’. This is a recommendation to buy a song. If the song then goes up in price, you earn a credit with a value depending on how much it rose in price.

It’s a(nother) great way of discovering the long tail of music.

Technorati Tags:

Did you see this?

February 11, 2007

Mr Geddes in cracking form as normal in OPINION://Did you see this? : well worth a good read and re-read. He points out that not only is technology great for making money but it’s great for forming opinions as well and that many of us take this democratisation of opinion forming for granted.

A good deal of Western governments and companies have twigged that market opinion is important, and that showing a good face to consumers is important and that actually doing the right thing is a good deal more profitable than not because of this. This was less so fifty years ago when it was easier for governments and companies to wave their hands Jedi-mind-trick-style, “Move right along there. There’s nothing to see”. A well-informed public is a dangerous thing. Nowadays the information comes thick and fast and as a famous law tells us “90% of everything is crud”. The only way to make sure that the 10% that isn’t gets through is to allow just about anything through.

So, getting different results on www.google.com from those on www.google.cn, or Verizon forbidding criticism using their own network (link is to great blog about Terms of Service for one Verizon service. The actual ToS seem to have been taken down) is initially a shock, but it’s the thin end of the wedge. Censorship is a sin of omission that constrains the natural political power of the network. Unless we all act, it’s going to become the norm, which would be a crying shame.

Technorati Tags:

What software development problems do agile best practices answer?

February 4, 2007

In Which best practice to implement first? I said that agile best practices are really answers to problems. The best way to identify the correct agile practice to implement first is to work out the root causes of your biggest software development problems. Let’s take an example that is common complaint from many business customers: how come our IT department delivers so little? Rather than just complain about this, let’s keep on asking ‘why’. We can list some of the products that our IT department produces:

  • Project plans
  • Project charters
  • Test plans
  • Software working in production
  • Estimates
  • Change requests
  • Status reports

Of these, what is most important to us? In fact, there is only one product which we really care about: software working in production. The others are simply products that we have been led to believe are required to deliver software on time and budget. From a lean point of view, these other products are ‘waste‘: they do not directly add value to the customer.
In my research I found that most of the time, it was not just a project manager delivering these management deliverables, it was the whole team: programmers, application development managers, testers, etc. So, why is IT spending so much time doing everything but what is essential to producing software?

The following is a snippet of a ‘Current Reality Tree’, a Theory of Constraints approach to describing how things work right now.
Plans and estimates are waste
A Current Reality Tree (CRT) can be read ‘A causes B’ or ‘A means B’, e.g. “Lots of time updating plans & estimates means less time for delivering software”. We can create a CRT by asking ‘why’ repeatedly. For instance, why do we spend less time delivering software? Because we spend lots of time updating plans & estimates. Why do we spend so much time updating plans & estimates? Because changes happen more frequently than we had planned. The power of a CRT comes from being able to identify some of the root causes to business issues. Some of the answers are more implicit assumptions than direct answers. e.g. Why do changes happen more frequently than planned? Not only because we keep on changing our list of priorities, but also because the business demands that IT produce a new set of plans, status reports and estimates of new delivery dates every time the priorities are changed.

So, how can we turn these problems into solutions? We need to tackle one or both of the two root causes identified in the CRT:

  • The business demands a plan-based approach
  • Multiple changing priorities

In my experience, changing either one of these brings a lot of great results very quickly.

At first glance, either of these seem to permeate most business environments. Can there be an alternative to a plan-based approach to building software? It’s to this type of question that agile best practices provide such great answers. For instance, a time-boxed deployment schedule where the schedule is fixed, but scope is allowed to vary is a non-plan based approach. If a feature takes an unexpected amount of time to deliver, it can slip to the next iteration. The impact of the change is small and the product that requires updating is the software itself. In contrast, in a plan-based approach, the team delivering the software needs to update plans, estimates and delivery schedules. The next steps are to identify how this time-boxed approach will work in practice. This is to ensure that it does not create additional business issues and to ensure that we have everything required for a successful implementation. In a way, this is just another way of continuing to ask ‘why’. Luckily, as we get deeper into the implementation, there will be other agile practices to help us, such as continuous integration and test driven development.

Technorati Tags: , , , ,