During resulting extinction events, the number of higher species is radically reduced, along with the number of individuals of the surviving species, making more space for evolution to act in the context of the prevailing environmental conditions.

It’s this relationship with our environment that may be the reason we evolved into our current form. Given our complexity and attendant vulnerability, the evolutionary response to our unpredictable world was to produce a more adaptable and flexible form.

Walking upright freed our hands and coupled to a bigger brain has allowed us to develop existing tool use and problem solving skills. In the natural world we’re puny creatures, but adaptation is our greatest asset, but one that can be applied in two ways.

Millions of years have passed and we’ve become accustomed to altering the inconvenient parts of our environment rather than adapting to new conditions, but one day we’ll come to a point where the magnitude of change is too great.

It’s inevitable that the current abnormal period of climate stability will come to an end, and my concern is that we’ve become too numerous and rigid in our social organisation to apply the fruits of our evolution to the task of rapid adaptation.

We’ve become optimisers rather than innovators, trying to extract every last drop instead of searching for different solutions. We assess everything in terms of it’s cash price and expend our efforts in developing new regulations. We fail to find the important solutions when we need them, should we be surprised?

Imagination is the best part of being human, and it needs time and intellectual freedom to thrive, commodities I’ve found to be increasingly rare in our modern world. A return to uncertainty may be what our species really needs to rediscover it’s full potential.

Tax credits were an obscure approach to returning public money to those most in need, but often the least likely to understand how get them. The system complexity justifies a tax credits section in the Revenue and Customs website.

Cutting VAT by 2.5% in order to stimulate the economy never seemed very likely to work. Unless ‘work’ is defined as creating additional work for businesses that need to cut cost. Several market analysts speculated this tax cut was administratively simpler than trying to get the Treasury to work out how to give tax refunds.

Finally, there’s the latest plan to encourage the employment of long term unemployed by offering employers £2500 for each individual. On Bloomberg this morning, Hugo Sellert — Head of Economic research at Monster Worldwide — was less than convinced. He was a little concerned about skewing the labour market: shouldn’t individual employment be determined on experience and skills, not whether there’s a handout?

My thoughts turned to another key discipline of Agile development, refactoring: leaving code cleaner, and easier to understand, than you found it. This isn’t done as a separate activity. Whenever you’re working on a particular piece of code, look at it as a whole and ask yourself, “could this be improved”?

Refactoring the legislative system of the Country would be a huge job, but done incrementally not impossible. Take an Agile approach and one day we might find we have a much less buggy society.

The Agile approach is more adaptable with respect to three key project variables; only the last of which, in my experience, is considered flexible in the waterfall world of engineering.

• Scope.
• Time.
• Resources.

Scope contraction.

Scope flexibility is something of a taboo subject. Scope is something that is added to in both a controlled manner — providing additional revenue — or uncontrolled creep. But the point of any project is delivering something that achieves the customers business goals. This is not necessarily the product that they, or the development team, initially envisaged.

One uncomfortably overspent project lead to the realisation that I could have achieved the business objective well under budget by actually drastically reducing the scope. It wouldn’t have delivered exactly what the customer expected, but it would easily have achieved their goal.

Which is more important, expectation or results? If you have a customer representative on the team it’s much easier to explain your rationale, and the chances are they’ll like the idea of results with less work as much as you do.

Timescales.

If you have a customer that doesn’t mind when you deliver, you’re a rare and lucky project manager, though you’ll never actually finish anything; deadlines do provide focus. So set plenty of deadlines, that’s what iterations and releases are about.

Try to answer the most pressing question as quickly as possible. Leave refinements and those ever present scope changes to the next iteration, it’s probably only a few days away.

This rapid cycle provides useful results, whilst allowing the flexibility to quickly change direction without that wasteful churn: just tidy this up a bit then I’ll be with you.

And the resources?

I’m afraid the project manager has to earn their money too. Line management will always have the urge to reassign any of your key people they feel aren’t being fully employed. It’s important to emphasise that the productivity of any team depends on preventing this happening.

Agile teams don’t strictly segregate workload on the basis of job descriptions, that’s why you need versatile individuals. Unfortunately, these are exactly the type of individuals that those managers will want to steal away. Removing the demarcation of tasks will help ensure everyone is kept busy and that work is conducted using the minimum number of people.

Better than the Waterfall.

I’ve found actual project goals shift too frequently for effective use of the Waterfall approach to project management. Using iterations within this framework always felt unnatural; how do you decide how may there will be and when will you actually deliver something?

An Agile approach perversely leaves me feeling more in control by worrying less about control. There are a huge array of Agile software development techniques, many of which can be adapted to other engineering disciplines.

For Software Engineering, I would recommend reading The Art of Agile Development. The Agile Alliance promote the use of Agile techniques, so take a look at the Manifesto for Agile Software Development upon which it’s all based.

Which programming platform to use for the server-side application? Whilst I have to admit that I’m not the greatest fan of PHP, it’s definitely the best option. Why? Because I need to run this application locally on a minimal server and PHP is available wherever you find Apache, and the skills should have some commercial value.

I’ve recently read a great deal about agile development, TDD and employing software design patterns. As part of this project I’d like to apply some of what I’ve learned.

A test framework.

Now I’m going to need a testing framework, and I’ve gone for SimpleTest. This framework not only provides unit testing, but the ability to create tests for web pages. I prefer to run my test suites from the command line, which is relatively easy to arrange with the TextReporter object. I’ve combined the whole thing with Apache Ant to automate most of the tasks in the project, including deployment.

Unfortunately, it appears that SimpleTest doesn’t play particularly well with PHP5, although they’re in the process of making the transition.

I’ve encountered the mass of error messages generated as the result of E_STRICT. This is easily solved by using a customised php.ini file as an option at the command prompt when executing the test code. Once this is done you can see the actual test messages!

A more significant problem is that the Mock object code cannot be called as static class methods in the way the documentation suggests. A little snooping through the code leads me to think that it’s due to PHP4 without the static keyword in the method headers required by PHP5. I don’t have a work-round for this, and I don’t want to have to alter all this code. I hope they address this as the transition to PHP5 continues, but at the moment my code is simple enough for me to write my own mocks.

When all is said and done, if you know how to use any of the xUnit test frameworks, SimpleTest is very easy to set-up and use.

Driving with tests.

Simple the tests may be, but using them to steer the direction of your coding effort takes a different mindset. The hardest part is learning which questions to ask when developing your tests. Asking the right questions about functionality will result in clean, precise code.

There’s always a temptation add just a little more functionality, but resist it. The point is to remain in control of the code at all times. When it’s not working, it must be because you’ve added new tests describing new functionality. The code should never contain functionality that hasn’t been demanded by a test. Good refactoring can produce beautiful code without breaking the tests — still in control.

I think I’m getting the hang of it in relatively simple cases, but there’s much more to learn. I’ve found it a very liberating way to develop software, whilst remaining in total control — you are using version control?

Patterns in the code

Whilst there are loads of MVC based frameworks out there, I want to know how it works first hand. This topic is worth an article of it’s own, and that’s what I’ll give it.

There’s a good chance that the core application model will need to implement a facade pattern, but lets not make any assumptions.