Category Archives: Agile

Automated Testing Patterns and Smells

Posted on by

Wonderful tech talk by Gerard Meszaros who is a consultant specialising in agile development processes. In this particular presentation Gerard describes a number of common problems encountered when writing and running automated unit and functional tests. He describes these problems as “test smells”, and talks about their root causes. He also suggests possible solutions which he expresses as design patterns for testing. While many of the practices he talks about are directly actionable by developers or testers, it’s important to realise that many also require action from a supportive manager and/or system architect in order to be really achievable.

We use many flavours of xUnit test frameworks in our development group at Talis, and we generally follow a Test First development approach, I found this talk beneficial because many of the issues that Gerard talks about are problems we have encountered and I don’t doubt every development group out there, including ours, can benefit from the insight’s he provides.

The material he uses in his talk and many of the examples are from his book xUnit Test Patterns: Refactoring Test Code, which I’m certainly going to order.

Automated regression testing and CI with Selenium PHP

Posted on by

I’ve been doing some work this iteration on getting Selenium RC integrated into our build process so we can run a suite of automated functional regression tests against our application on each build. The application I’m working on is written in PHP, normally when you use Selenium IDE to record a test script it saves it as a HTML file.

For example a simple test script that goes to Google and verifies that the text “Search:” is present on the screen and the title of the page is “iGoogle” looks like this:

  1.  
  2. <html>
  3. <head>
  4. <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  5. <title>New Test</title>
  6. </head>
  7. <body>
  8. <table cellpadding="1" cellspacing="1" border="1">
  9. <thead>
  10. <tr><td rowspan="1" colspan="3">New Test</td></tr>
  11. </thead><tbody>
  12. <tr>
  13.     <td>open</td>
  14.     <td>/ig?hl=en</td>
  15.     <td></td>
  16. </tr>
  17. <tr>
  18.     <td>verifyTextPresent</td>
  19.     <td>Search:</td>
  20.     <td></td>
  21. </tr>
  22. <tr>
  23.     <td>assertTitle</td>
  24.     <td>iGoogle</td>
  25.     <td></td>
  26. </tr>
  27.  
  28. </tbody></table>
  29. </body>
  30. </html>
  31.  

You can choose to export the script in several other languages, including PHP, in which case the test script it produces looks like this:

  1. span class=”st0″>’Testing/Selenium.php’‘PHPUnit/Framework/TestCase.php’"*firefox", "http://localhost:4444/""/ig?hl=en""Search:""iGoogle"

The Export produces a valid PHPUnit test case that uses the Selenium PHP Client Driver(Selenium.php). Whilst the script is valid and will run you do need add a little more to it before the test will correctly report errors. As it stands all errors captured during the test are added to an array called verificationErrors, by catching the assertion Exceptions that are thrown when an assert fails, in other words if you ran this test as it is, and it did fail you wouldn’t know! To correct this we need to do two things. Firstly, each assert needs to have a message added to it which will printed out in the test report if the assert fails. Secondly we need to modify the tearDown method so that once a test has run, it checks the verificationErrors array, and if any failures have occurred, fails the test. After making these changes the PHP test script looks like this:

  1. span class=”st0″>’Testing/Selenium.php’‘PHPUnit/Framework/TestCase.php’"*firefox",
  2.                          "http://localhost:4444/""VERIFICATION ERRORS:""\n""/ig?hl=en""Search:"),
  3.                "The string Search: was not found""iGoogle",
  4.                    $this->selenium->getTitle(),
  5.                    "The page title did not match iGoogle."

Obviously, I have also given the PHP Class and test function slightly more meaningful names. Now you have a PHP Unit Test case that will use the Selenium PHP Client Driver with Selenium Remote Control to launch a browser, go to the specified URL, and test a couple of assertions. If any of those assertions fail, the tearDown method fails the test … pretty cool, right?

Well now it get’s better. Because the Selenium Client Driver has a published api which is pretty easy to follow, there’s no reason why you can’t just write test cases without using Selenium IDE … for those who want to you could even incorporate this into a TDD process. But for all this to hang together we need to be able to run a build, on a Continuous Integration server which checks out the code, runs unit tests and selenium regression tests against that code line, and only if all tests succeed passes the build.

We are currently using ANT, and CruiseControl to handle our CI/Automated build process. When running the automated suite of tests we need to ensure that the Selenium Remote Control server is also running which creates some complications. The Selenium Remote Control server takes several arguments which can also include the location of a test suite of html based selenium tests – which is really nice because the server will start, execute those tests and then end. Unfortunately you can’t invoke the server and pass it the location of a PHP based test suite. This means you need to find a way to start up the server, then run your tests, and once they are complete, shut the selenium server down.

He are the ANT targets that I have written to achieve this, if anyone can think of better ways of doing this I’d welcome any feedback or suggestions, to run this example you’d simply enter the command “ant selenium” :

  1.  
  2. <target name="selenium" depends="clean, init" description="Run the Selenium tests">
  3.   <parallel>
  4.     <antcall target="StartRCServer" />
  5.     <antcall target="RunSeleniumTests" />
  6.   </parallel>
  7. </target>
  8.                
  9. <target name="StartRCServer" description="Start the Selenium RC server">
  10.   <java jar="dependencies/SeleniumRC/lib/selenium-server.jar"
  11.         fork="true" failonerror="true">
  12.     <jvmarg value="-Dhttp.proxyHost=host.domain.com"/>
  13.     <jvmarg value="-Dhttp.proxyPort=80"/>
  14.   </java>
  15. </target>
  16.    
  17. <target name="RunSeleniumTests" description="RunAllSeleniumTests">    
  18.   <sleep milliseconds="2000" />
  19.   <echo message="======================================" />
  20.   <echo message="Running Selenium Regression Test Suite" />
  21.   <echo message="======================================" />
  22.   <exec executable="php"
  23.        failonerror="false"
  24.        dir="test/seleniumtests/regressiontests/"
  25.        resultproperty="regError">
  26.        <arg line="../../../dependencies/PHPUnit/TextUI/Command.php –log-xml ../../../doc/SeleniumTestReports/RegressionTests/TestReport.xml AllRegressionTests" />
  27.   </exec>
  28.   <get taskname="selenium-shutdown"
  29.     src="http://localhost:4444/selenium-server/driver/?cmd=shutDown"
  30.     dest="result.txt" ignoreerrors="true" />
  31.                    
  32.   <condition property="regressionTest.err">
  33.     <or>
  34.        <equals arg1="1" arg2="${regError}" />
  35.        <equals arg1="2" arg2="${regError}" />
  36.     </or>
  37.   </condition>
  38.  
  39.   <fail if="regressionTest.err" message="ERROR: Selenium Regression Tests Failed" />               
  40. </target>
  41.  

A couple of notes, the reason I have to use a conditional check at the end of the selenium target is because, if the exec task that runs the PHP tests was set to failonerror=true then the build would never reach the next line which shuts the Selenium RC server down. To ensure that always happens I have to set the exec to failonerror=false, but this means I have to check what the result was from the exec. Which if successful will return 0, if test failures exist will return 1, and if there were any errors (preventing a test to be exectuted ) will return 2. Hence the conditional check sets regressionTest.err if either of these latter two conditions are true.

Also in order to start up the server, which could take up to a second, but can’t be sure precisely how long. I have to use the Ant Parallel task, which calls the task to start the server and the task to run the tests at the same time. The task to run the tests has a 2 second sleep in it, which should be more than enough time to allow the server to start. This all kind of feels a little clunky, but at the moment it does work very well.

In a nutshell, thats how you integrate PHP based Automated Selenium Regression tests into a continuous build.

Greeks vs Romans. Adaptive vs Plain-Driven development.

Posted on by

Came across this wonderful essay over at Hacknot today. The essay starts off by decrying this assertion made by Raghavendra Rao Loka, in February’s 2007 edition of IEEE Software:

“Writing and maintaining software are not engineering activities. So it’s not clear why we call software development software engineering.”

The author of the essay goes onto offer a brief rebuttal of this this based on some comments by Steve McConnell, and pointed out quite rightly in my opinion that:

Software development is slowly and surely moving its way out of the mire of superstition and belief into the realm of empiricism and reason. The transition closely parallels those already made in other disciplines, such as medicine’s evolution from witchcraft into medical science.

What I found really insightful though was how the author likened these two views ( Loka vs McConnell ) to another conflict:

These two represent the age-old conflict between the engineers and the artists, the sciences and the humanities. In the software development domain, some have previously characterized it as the battle between the Greeks and the Romans.

He then applies this same metaphor to the wider issue of adaptive vs the plain-driven approaches to software development and in doing so offers an interesting perspective on the two schools of thought:

By now you will probably have recognized the analogue between the cultural divide separating the Greeks and Romans and the methodological divide between adaptive and plan-driven approaches to software development.

We can think of the Greeks as representative of Agile Methods. The focus is upon loosely coordinated individuals whose talent and passion combine to produce great artefacts of creativity. Any organizational shortcomings the team might experience are overcome by the cleverness and skilful adaptivity of the contributors.

Alternatively, we can consider the Romans as representative of plan driven methods, in which the carefully engineered and executed efforts of competent and well educated practitioners combine to produce works of great size and complexity. The shortcomings of any of the individuals involved are overcome by the systematic methods and peer review structure within which they work.

It’s a wonderful analogy that I think illustrates some of the differences between the two approaches in a way that most practitioners would readily understand and perhaps even agree with. Which is the right approach? I guess it depends on you, your project but most importantly the kind of people you have in your team. I have certainly spent a considerable amount of time extolling what I believe are the virtues of the agile methodology on this blog.

I spent several years working in a very Roman-esque organisation and I’d probably argue that the competent and well educated practitioners in such organisations rarely fit either of those terms. Probably because the very nature of such systems require those working within that confine to accept a certain level of conformity. Consequently individual flair, creativity or even imagination are less important than the uniformity that such organisations require – a sort of fill-in-the-blanks approach to development where your responsible for only those small pieces assigned to you, and whether you necessarily know what the bigger picture is or even understand it isn’t important because some more senior in the team who assigns you your tasks does know. This often results in developers feeling disaffected or perhaps less likely to feel any sense of personal ownership or even responsibility, because they know they aren’t in a position to be responsible for anything.

I do find myself agreeing that part of what makes agile teams successful is this notion of heroics on the part of individuals. It does work well when you have talented individuals who can work together in a reasonably small scale. How well does that scales up? … I can’t personally answer that question?  I’ve read plenty of accounts and listened to the likes of Scott Ambler explain how agile can work on large scale projects. I must admit I’m not sure if I’m convinced of this. … but that’s only because of my earlier point that this decision needs, in part, to be based on the type of people you have your in team.

Our development group at Talis is quite small,at the moment no more than 20 people – and it’s not for a lack of trying, were constantly trying to recruit people but we look specifically for skilled developers who could fit into the culture that we have. Individuals who are self motivated, self learners who take a great deal of personal pride in what they do, take responsibility and also want to have a sense of ownership over what they are building. As a result we tend to be quite jealous of who we let into the team, but again that’s probably something that is unique to our little group and says more about us than the Agile process.

I do find myself partly agreeing with the conclusion the author of the essay makes:

I favour a development method that is predominantly Greek, with sufficient Roman thrown in to keep things under control and prevent needless wheel spinning. The Greeks are a great bunch of guys, but they tend to put too much emphasis on individual heroics, and pay too little attention to the needs of the maintenance programmers that will following in their path. The Romans are a little stuffy and formal, but they really know how to keep things under control and keep your project running smoothly and predictably

 I don’t agree that, in terms of software development,  the Roman approach was ever truly able to keep things under control or necessarily running smoothly even predictably. If it was we wouldn’t have so many examples of failed projects that went over budget, went over time and totally failed to deliver what the customer actually wanted.

I personally do prefer a predominantly Greek approach and I do see methodologies such as SCRUM imposing the right level of Roman-esque control and structure to keep the project moving along smoothly and predictably, with the added bonus that the customer actually gets what they want.

The Role of Testing and QA in Agile Software Development

Posted on by

In our development group at Talis We’ve been thinking a lot about how to test more effectively in an agile environment. One of my colleagues, sent me a link to this excellent talk by Scott Ambler which examines the Role of Testing and QA in Agile Software Development.

Much of the talk is really an introduction to Agile Development which is beneficial to listen to because Scott dispels some of the myths around agile, and offers his own views on best practises using some examples. It does get a bit heated around the 45 minute mark when he’s discussing Database Refactoring, some of the people in the audience were struggling with the idea he was presenting which I felt was fairly simple. If you really want to skip all that try to forward to the 50 minute mark where he starts talking about sandboxes. What I will say is that if your having difficulty getting Agile accepted into your organisation then this might be a video you want to show your managers since it covers all the major issues and benefits.

Here’s some of the tips he has with regard to testing and improving quality:

  • Do Test Driven Development, the unit tests are the detailed design, they force developers to think about the design. Call it Just-in-time design.
  • Use Continuous Integration to build and run unit tests on each check-in to trunk.
  • Acceptance Tests are primary artefacts. Don’t bother with a requirements document simply maintain the acceptance test since the reality is that all testing teams will do is take that requirement and copy it into an acceptance test, so why introduce a traceability issue when you don’t need it. http://www.agilemodeling.com/essays/singleSourceInformation.htm
  • Use Standards and Guidelines to help ensure teams are creating consistent artefacts.
  • Code Reviews and Inspections are not a best practise. They are used to compensate for people working alone, not sharing their work, not communicating, poor teamwork, and poor collaboration. Guru checks output is an anti-pattern. Working together, pairing, good communication, teamwork should negate the need for code reviews and inspections.
  • Short feedback loop is extremely important. The faster you can get testing results and feedback from stakeholders the better.
  • Testers need to be flexible, willing to pick up new skills, need to be able to work with others. They need to be generalising specialists. The trend that is emerging in agile or the emerging belief is that there is no need for traditional testers.

Scott is a passionate speaker and very convincing, some of the points he makes are quite controversial yet hard to ignore – especially his argument that traditional testers are becoming less necessary. I’m not sure I agree with all his views yet he has succeeded in forcing me to challenge my own views which I need to mull over and for that reason alone watching his talk has been invaluable.

End of sprint, SCRUM and why I’m feeling so good

Posted on by

We’ve just reached the end of our eighth sprint on the project I’ve been working on. On Monday we’ll be doing our end of sprint demonstrations to customers as well as internally to the rest of the company and I have to say I’m feeling quite good about it. It’s a lovely day today feel like I need to chill (or as Rob suggested – maybe I need to get a life 😉 ) anyway I’ve been sitting here reflecting on this month and there’s a few things I want to talk about.

I’m fairly new to the SCRUM methodology, in fact this is the first project I’ve worked on that formally uses it. Our development group here at Talis has adopted the SCRUM process across all of our current projects with what I feel has been a great deal of success.

For me personally the transition from traditional waterfall approaches to agile methodologies has been a revelation in many ways. Before joining Talis I’d spent a number of years developing software based on traditional waterfall methodologies. What was frustrating with these traditional approaches was that you’d spend months capturing and documenting requirements, you’d then spend a while analysing these requirements and then designing your software product, before implementing it and then testing it. Any changes to the requirements invariably meant going through a process of change impact analysis and then going through the whole process again (for the changed requirements), which naturally increases the cost to the customer.

A side effect of which, from the perspective of the customer, was that changing requirements during the project was a bad idea, because of the extra costs it would incur. A consequence of this is that customers would often take delivery of systems which after a couple of years of development, don’t actually satisfy the requirements that they now have. These same customers would then have to take out a maintenance contract with the vendor to get the systems updated to satisfy their new requirements.

From a developers point of view, I often found this to be very demoralising, you knew you you were building something the customer didn’t really want, but the software house you work for wants to do that because they have a signed off requirements document and contract that guarantee’s them more money if the customer changes their mind. I often found that when we reached the end of a project, the delivery of that software to the customer was a very and nervous and stressful time. The customer at this point has not necessarily had any visibility of the product so there’s usually a couple of months when your organisation is trying to get them to accept the product – which invariably led to arguments over the interpretation of requirements – and sometimes scary looking meetings between lawyers from both sides.

There was always something very wrong with it.

Since joining Talis, and transitioning to agile methodologies I can finally see why it was so wrong, and why agile, and in this case SCRUM, work so well.

For one thing, I’m not nervous about the end of sprint demonstrations. 🙂 The customers have been involved all along, they’ve been using the system, constantly providing feedback, constantly letting us know what were doing well, and what we need to improve on.

Our sprints have been four weeks long, which means at the beginning of the sprint we agree which stories we are going to implement based on what the customers have asked us for, these can be new stories that have been identified, or stories from the backlog. The customers have an idea, from previous sprints, what our velocity is – in other words they, and we, know how much work we can get done in a sprint so when we pick the stories for the sprint we ensure we don’t exceed that limit. This keeps things realistic. Any story that doesn’t get scheduled in for the sprint because it was deemed less of a priority than the stories that are selected gets added to a backlog.

This iterative cycle is great! For one thing customer’s are encouraged to change their minds, to change their requirements, because they then have to prioritise whether that change is more important than the other items on the backlog. They are empowered to choose what means the most to them, and that’s what we give them ! The customer doesn’t feel like the enemy, but an integral part of the team, and for me that’s vital.

As a developer it feels great to know that your customers like your product … and why shouldn’t they, they’ve been involved every step of the way, they’ve been using it every step of the way.

I’ve only been here at Talis for ten months, and in that time I’ve had to constantly re-examine and re-evaluate not only what I think it means to be a good software developer but pretty much every facet of the process of building services and products for customers. For me it’s been an amazing journey of discovery and I’m pretty certain it’s going to continue to be for a very long time.

The really wonderful thing though is that in our development group I’m surrounded by a team of people who believe passionately that it’s the journey and how we deal with it that defines us, and not the destination. So we are constantly looking for ways to improve, that in itself can be inspiring.
So yeah … I feel good!

Our development group is always looking for talented developers who share our ethos and could fit into the culture we have here. If you’d like to be a part of this journey then get in touch with us. Some of us, including myself, will be at XTECH 2007 next month, so if your attending the conference come and have a chat with us.

Why software sucks

Posted on by

Over on slashdot theres an excellent little article and debate around the issue of why software sucks. The slashdot article points to this news story on the Fox News Network. that discusses the book by David Platt entitled “Why software sucks …. and what you can do about it“. I haven’t read the book yet but I’ve added it to my things to read list. The debate on slashdot though is actually quite interesting and worth reading in its own right. What interests me is how some of the sentiments echoed in the articles and discussions resonate around my earlier views that programmers arent usability experts, and until we start developing software centred around the user … software will continue to suck.

Code reviews at Google with Mondrian

Posted on by

Another excellent Tech Talk. Our development group at Talis has been experimenting with different ways to carry out code reviews and I think its safe to say were still trying to find what works best for us.

I think this tech talk is very relevant not just to the discussions were having internally, but to any organisation that is serious about wanting to ensure that they are developing great, maintainable software.

ea_spouse : profit at the cost of human dignity

Posted on by

My copy of The Best Software Writing I – selected and introduced by Joel Spolsky arrived the day before yesterday. I finally managed to start reading it last night after getting back from a truly magical evening at the Chinese State Circus. The book is a collection of essays/posts on online blogs that Spolsky has brought together as examples of simple goodle writing that engages the reader and captivates them. Spolsky introduces each essay with his own take on the subject matter. The essay I chose to read first was entitled EA – The Human Story. Anyone who knows me, knows I play several online games (most FPS ones), and I have a great interest in the gaming industry in terms of the products and technologies that they produce.

It’s safe to say that I was not expecting to be moved quite as much as I was by this account, which you can read online in its entirety over at http://ea-spouse.livejournal.com/. Before I go any further I will say this, I believe that ANYONE working in the software industry or in human resources, in fact everyone should read the essay.

It’s written by the spouse of an Electronic Arts employee who wrote this under the anonymous moniker ea_spouse, she chose to remain anonymous because in her own words she has “no illusions about what the consequences would be for my family if I was explicit“. Her account dramatically made the world aware of the shocking sweatshop-like labor practises at EA. It’s important to point out that this account was originally written in 2004 and since it was first published the controversy it generated has led to class action law suits against EA, as well a shedding light on what appears to be a commen trend within the gaming industry.

She describes what her family has to endure as her spouse is forced to work in excess of 85 hours a week for months on end, or in her own words:

Every step of the way, the project remained on schedule. Crunching neither accelerated this nor slowed it down; its effect on the actual product was not measurable. The extended hours were deliberate and planned; the management knew what they were doing as they did it. The love of my life comes home late at night complaining of a headache that will not go away and a chronically upset stomach, and my happy supportive smile is running out

It’s a heart wrenching expose that both captivates and evokes an extremely emotional response in you as you read it. As she laments the forced hours without any overtime or compensation, or even time off for employees you cant help but feel sickened. I had to put the book down and walk away for a moment when she wrote:

“If they don’t like it, they can work someplace else.” Put up or shut up and leave: this is the core of EA’s Human Resources policy. The concept of ethics or compassion or even intelligence with regard to getting the most out of one’s workforce never enters the equation:

Like anyone in the software industry you accept that you do have to work long hours sometimes as deadlines begin to loom, most of the developers that I have known dont mind this, but commonsense alone should tell us that this should always be the exception – never the norm. Ultimately it’s un-sustainable. We’re all human beings, we have lives outside of our work, other interests to persue, other dreams to achieve. ea_spouse ends her account with this …

…when you keep our husbands and wives and children in the office for ninety hours a week, sending them home exhausted and numb and frustrated with their lives, it’s not just them you’re hurting, but everyone around them, everyone who loves them? When you make your profit calculations and your cost analyses, you know that a great measure of that cost is being paid in raw human dignity, right?

Before joining Talis I used to work for an organisation, where I did clock up close to 70 hours a week for sustained periods. Of course no-one actually forces you, your just left to wander if you want the stigma of being labelled not a team player. I can only comment from my own perspective but I have no doubt that much of the apathy, cynicism and even contempt I had for the industry was a product of just how soul destroying it is to wake up, go to work, come home, sleep for a little and then wake up and go to work again. Your depressed, your constantly tired, your irratable, you become less and less attentive … to the point where you dont even sense someone running up behind you with a lead bar!

But what doesnt kill you, generally makes you stronger … at least thats something I try to believe. As I Read ea_spouse’s account, and thought about my own experiences as a developer working extended hours for sustained periods, I was immediatly able to contrast that with what things are like now.

For me Talis is a very different kind of environment to work in as a developer. I dont know whether its because we’ve embraced agile methodologies that are based around the principle of sustainable iterations of work, or whether its because the people I work with and work for genuinley care about the wellbeing of every member of the team. Or as I suspect its probably a combination of both. Our iterations in Skywalk are weekly, the small team on average completes around 15 units of work per week (our velocity – dont ask me to define what our units represent … I always quote my estimates in donuts! 😉 ), but I recall how our programme lead reacted a few months ago when the team over a couple of iterations averaged twice to three times that figure.

Our programme lead on skywalk, Ian Davis, is probably one of the finest programme mangers I have ever worked with. Probably because he doesnt think of himself as a programme manager. He’s extremely goal driven and yet a humanist who puts the well being of his team before anything else. As a team leader he’s a pragmatist, but it’s his charm and his passion that has helped bring together bunch of talented geeks and focused them into a team in every sense of the word. Anyway a few months back our velocity shot up, we were coming to the end of the development on a research prototype we call, Cenote, we wanted to have the piece up and running so Paul could show off some of our achievements at a conference in Canada. There wasnt a real requirement for the prototype to be made available, it was always a nice to have. But the team wanted to showcase its work, we take a great deal of pride in what we do. Ian was on vacation and in his absence we simply plowed on got it all done and delivered. When he came back and checked our velocity, he was appreciative yet told us that he didnt want us to make a habit of that because it wasnt sustainable. He then planned our next iteration to be around half our normal average velocity on the grounds that he wanted to make sure we all got a bit of rest. I’d never known a programme manager to react like that … or for a company to let him.

Outsourcing developers abroad … Do people still really think its a good idea?

Posted on by

Had an interesting evening went to the gym and ran into an old friend I’ve not seen in a few years. We sparred for a bit (its a guy thing … guess we wanted to see which of us had improved the most since our last … encounter … it was me of course not that I’m insanely competitive … honest!)

Anyway afterwards we went to to grab a bite to eat and catch up on what we’ve both been up to. We both work in the IT industry and love development but we tend to have differing views on a lot of things ( Listen J were not starting the Java vs .NET argument on my blog if you do I’ll really kick your ….). Anyway J and I both used to work for the same company and the senior management of that organisation has recently announced that its going to outsource the development of some its long term projects overseas to India, citing that engineering talent over there is cheap and thus far more cost effective … but they intend to run the projects from over here. As a result my friend, like many of his colleagues are obviously worried about their futures and whether the company will want to retain their services as developers for much longer. Anyway this kind of got me thinking …

I’m not going to pay credence to any of those boorish, tired and lamentable arguments about how its morally wrong to take UK jobs and hand them to people overseas. The fact is we live in a global economy and we have to accept that we need to remain competitive in that economy. Besides I believe that kind of xenophobia generally tends to cloud the issue and overshadow far more important reasons as to why outsourcing is a bad idea for our industry.

I remember towards the tail end of the 90’s when venture capitalists where really pushing the idea of outsourcing development to places like China and India it’s cheaper, more cost effective and will help the organisations overall operational effectiveness. I’m of the opinion that this was generally because they looked at other industries where that model worked really well, I guess what they thought was if Matel can manufacture toys abroad cheaper, why cant we get software written abroad cheaper, right? Lots of large firms bought into this thinking Oracle and Hewlett Packard are just two examples of companies that followed this trend … only to slowly distance themselves after encountering the problems I touch upon below.

The problem though, is that writing code isn’t something you can translate into an assembly line. What I think the people pushing this type of outsourcing failed to comprehend, and seemingly still dont understand is that farming out development overseas doesn’t lead to innovation. The idea that you get a a large group of programmers together and they’ll just produce cool code – doesn’t work! I remember at university I did an elective in post-war Japanese history (wish I could tell you that I did this cos it was interesting but the truth was the lecturer was the hottest chick I’d ever …*off daydreaming*), anyway one of the things we were taught was that the japanese rebuilt their economy around their manufacturing industry, using automated methods of production and rigourous quality control. Through all of this they actually revolutionised manufacturing industry globally the effects of which are still being seen today.

Towards the end of the seventies and into the eighties Japanese companies tried to set up software factories where they basically got a shed load of developers together and tried to apply their tried and tested manufacturing experience to writing software … they failed miserably and learnt that putting loads of developers together doesn’t create innovative software. The reason is that writing software isn’t something that translates into a purely mechanical activity – like making a toy or a car. So none of their tried and tested rules applied.

Someone famously once said every line of code is a design decision, I’m struggling to remember who it was [insert clever guys name here]. But that single statement embodies for me what the real problem is with outsourcing projects abroad. You loose sight of the decisions that the developers are making as they piece together the product from your requirements. Farming out to developers overseas successfully means you have to pay meticulous attention to the details of what is being produced, and that’s damn difficult when you factor in communication problems, cultural differences and attitudes, and like it or not glaringly obvious fact that this model makes it difficult to be flexible or be able to react quickly to changes in your market place.