Development Gotchas and Silver Bullets

I feel tempted this week to just do a very short post and encourage the use of the URL links to a couple of great posts on software development, and urge that the time is spent on reading them. Both links reflect issues around changing the way development is done, in one case around the adoption of Agile to build fast, small pieces of code, and the other provides 'nine gotchas' to understand about developing on and for the cloud.

Software development is changing and has to change in respect of business calling for a different type of requirement; one that has to be done faster, and requires frequent changes in new front office situations in response to the market, so more and more people turn to considering Agile. Esther Derby has interesting posts on this topic both in terms of the use of the term as applied to a business but also a great post that sums up Agile development under the title of 'Still No Silver Bullets'

Right at the end of the post comes what for me is the key remark; No method, or set of methods can improve results unless managers also change the way they do their work. I have seen some real examples of how tough it is to shift from ingrained habits and what previously were good practical ways of doing things based on years of experience. Nothing unusual, it's a standard human reaction. But that's not necessarily true. The younger programmers are naturals for the shift to Agile, but it feels wrong to allow them to proceed in this way without an experienced project manager and plan. The answer is to start off with some developments that classified as experiments with business managers who want to help change the game.

Right now it's quite likely that some of those business managers and young programmers are experimenting in this manner using externally based resources, i.e. cloud-based services. Bob Violino posted on InfoWorld a great piece under the title of 'Cloud Development: 9 gotchas to know before you jump in' . This is a longish read, but well worth the effort. Tie this practical advice together with a clear plan to pilot development and deployment in new ways to meet new business challenges and you are more than likely going to end up with success.

I looked around to find a good source of information on best practices, or even gotchas on Agile, to go with this post. Much to my surprise most of the content was written in 2006 to 2008, and therefore I am suspicious as to the applicability to some of today's issues, foremost of which is a significant change in business requirements and deployment methods. Okay, I suppose the basic approach doesn't change, and therefore is relevant, but I kept digging and to my surprise discovered that HP offers a pretty comprehensive range of documents on the topic . It seems that they are less interested (biased?) in development tools and more interested in good outcomes that will run well on their products!

So a short post to encourage a clear departmental move to pilot development in a new environment, using new methods, against new requirements, and most of all to keep current management and methods 'hands off'. The learning experience and objective should consider that some parts won't work, and even that partial failure is a learning outcome. That's where the experienced managers and developers come into it, figure out what, why and how, to get it right, and both old and new will have a hand in building new best practices.

Remember the business schools' mantra for launching new products into markets is now fail fast and fail well, in order to find the winners. That means software development has to change to fit with new business practices!