Some would not be surprised to hear that even as a developer I was always looking to do the least amount possible to deliver the goal of what I was working on – ie. I was always looking at ways to maximise my effort by trying my best not to do the same thing twice and would pull my hair out (look at my picture) trying to see if I could automate what I was doing.
As a manager, this deep sense has grown into a desire to incorporate some of the core practices below that I feel epitomize a good development team and should be in a Technology Manager’s arsenal.
- Refactoring as you develop
- Drive for automated regression testing
- Automate your builds – Continuous Integration
- Industrialise your build process
- Agile Development Practices
These of course, are not goals in and of themselves, as they deliver monetary and time efficiencies due to:
- Lower development costs
- Lower maintenance costs
- Faster time to market
- Higher quality code
- The deliverable is more adaptable to changes that may arise
Refactoring as you develop
“Leave things better than you found them” is the old adage. In code we instinctively know that without refactoring, the design of the program will decay over time and that poorly designed code usually takes more code and time to get it to do the same things.
It’s often the case that on returning to code that we or others had previously written it could take a while to understand the functional design. One way of helping that is to refactor the code where needed to help familiarise ourselves with the code.
As managers we should be aware and genuinely concerned with quality as the lack of it usually comes back to bite us sooner than we think. We should not be obsessed with refactoring but should encourage it in our teams as on-going practice as they work.
Drive for Automated Regression Testing
We’ve all experienced it when a fix for something on our coding projects ends up breaking another part of the project. Automated regression testing is our insurance policy against this. As managers, if we are inheriting an existing project that lacks this insurance policy, we should require the development of an automation suite of tests that start off by testing our ‘egg on face’ key functionalities that we build on over time. If we are starting off on a new project we should encourage that each business functional story should have automated tests that test their acceptance criteria. I know the above is a rather simplistic view of testing but this blog is only meant to be a summary of the key processes I think improve a software development team.
Having this approach to testing means that; developers spend less time bug fixing especially into the late hours of the night after a major release, managers push out better quality products that have had their risks identified earlier with less screaming customers, testers end up testing things once and not spending most of their time and company money on manual drudge work.
There are many tools and frameworks out there now to enable this to happen such as:
And many more…
Automated Builds
Continuous Integration is the practice of automatically triggering a code build and running of unit and regression tests whenever a change is made to the code base. This provides instant feedback to developers and helps to keep the code base always close to a ‘ready to release’ state. Build problems are caught earlier, either by the builds failing or the tests.
Most development teams don’t automate their release process as it seems such a huge task to do and lack at times their managers support to do it. I would advise from experience that this is such a huge time saving exercise and is worth every penny. At one organisation that I pushed for the implementation of this, our build process to go into an environment could take upwards of a week. After implementing this the build took a few minutes
This is now a normal and fundamental practice amongst many agile development teams and reaps benefits such as; accelerated code release time, improved build quality, elimination of dependency on key personnel etc…
A good book for this is Continuous Integration – Steve Matyas and Andrew Glover
Industrialise Build Process
I’ve separated this from the above Continuous Integration as Continuous Delivery (Jez Humble & David Farley book), an Industrialised Build Process, deals more holistically with the build, deploy, test and release process. For me it is reaching that peaceful state of knowing that you can rebuild any server in your development or release environments at the click of a button because your server configuration scripts and tests, in version control, are being kept upto date regularly.
Benefits are that our development teams and their processes are so streamlined that there are no pieces of infrastructure lying around whose configuration is unknown or hidden in someone’s head that has probably left the organisation! When problems like this occur, with no configuration scripts, it can cause significant downtime with added stress and effort to fix.
Added benefit is knowing that your tests are consistently testing against the same configuration of environment as the same configuration scripts have created them. If tests pass in the Test environment they should pass in Pre-Production, UAT and Production, making for a smoother deployment and maintenance process to live.
Agile Development Practices
A research report published by Forrester in May 2010 showed that agile is becoming mainstream. A total of 35 percent of surveyed organisations described their primary development method as agile. Moreover, 11 percent said Scrum was the most popular agile development approach. In another survey, Forrester examined the level of agile adoption and found that 39 percent of the surveyed organisations considered their implementation mature.
I’m not going to argue the pro’s and cons of Agile vs Waterfall here but suffice to say that for most, if not all projects, I have come across agile development practices have been successful in their delivery. The greatest ideological differences for me are that Waterfall assumes that it is possible to have a near perfect understanding of the requirements before you begin while Agile embraces the reality of change.
So with Agile small teams work together with the real stakeholders to define quick prototypes or proofs of concept to explain the problem to be solved. The team then defines the requirements with the stakeholder for the whole project at hand but then agree to bite of a small working deliverable set of features in a short cycle – iteration. Work on this iteration begins and at the end the stakeholder is shown the results and a further iteration is discussed, according to the current requirements, to continue to deliver the whole with each subsequent iteration.
With Agile customer satisfaction is the primary measure of success rather than performance to plan but there is still a plan and planning. This is split out over the Release Planning, Iteration planning and daily stand ups. This makes for a high-speed development schedule that can only succeed when coupled with the automated process discussed above.
There are clear processes in Agile for it to work and succeed, for example, users must review and approve changes before they are merged into the baseline code, developers must review each other’s code and code must be unit tested and have good test coverage. These process though give greater freedom to development within a light-handed enforcement framework that is inductive of success.
For more on Agile check out the Agile Manifesto and the Agile Alliance or visit us for Agile Transformation Consulting or Implementation – HarringtonStarrTech.com
