Reg Reader Workshop Reader research conducted via the Reg Technology Panel over the last few years has consistently indicated the importance of application development to organisations large and small. Contrary to some of the things we hear, the need for software design, build and maintenance capability has not been killed by packaged applications, and certainly not by some of the latest ideas such as software as a service (SaaS) and cloud computing.

But it is true to say that things have been evolving steadily within the application development domain itself. The proliferation of scripting languages, rapid development frameworks, collaborative open source projects etc, coupled with the emergence of the ‘perpetual beta’ concept we have seen become commonplace in the online service provider world, has shaken everything up and directly challenged some of the traditional ways of doing things.

Against this background, it was interesting to get feedback from Reg readers in the latest workshop on some of the fundamental practicalities of managing software development in various different scenarios. Having worked through the insights coming out of your comments and poll responses, there are three main messages that come across strongly:

Lesson 1: Effective management is key to everything

While discussions of how to enable effective software development can quickly turn to tools and techniques (more of that below), it is very telling that two of the top three ranked criteria identified by Reg readers for creating the perfect development environment were management-related. Of the 670 readers participating in our poll, over 80 per cent gave “Respect, realistic expectations and understanding from management” and “Strong leadership of dept/team” an importance rating of 4 or 5 on a scale of 1 to 5. This was regardless of whether respondents were developers, team leaders or managers, or whether they worked in larger or smaller development shops. Over 60 per cent went on to highlight “Protection of developers from external pressures” as a key requirement of those managing the development function.

Easier said than done, perhaps, but when such requirements figure twice as prominently “Top of the table remuneration”, you can almost feel the pain of developers’ lives, and productivity, being negatively affected by management issues. We can infer from this that one of the key imperatives for optimising the development process is a two-way objective dialogue between the development organisation and business sponsors or stakeholders, in which priorities, constraints, dependencies and expectations are properly discussed and managed. Unfortunately, the danger is that you end up with a vicious circle in which development teams are asked to deliver against unrealistic objectives, have their objections overruled, and subsequently fail, which means next time around, they have more of a credibility problem than ever, so find it even more difficult to stand their ground.

The key to breaking such spirals is education, relationship management and, where necessary, effective internal negotiation. A trick that seems to work for some is putting relationship managers in place as go-betweens or facilitators. These are not necessarily your best developers, or even your most senior managers, but the silver tongued animals that are comfortable building a rapport with users and sponsors, and not afraid to stand their ground under pressure when laying out options. In any event, strong leadership and air cover is going to important for things to work well.

Lesson 2: A balance must be struck between structure and ‘creativity’

Turning to the internal workings of the development function, some interesting insights were prompted by a discussion about whether today’s programmers are more creative than their counterparts of 20 years ago (see here). The message came through loud and clear that while modern tools and environments allow developers to work up creative front ends rapidly and flexibly, the need for sound analysis and design has not gone away.

Tempting though it is to just prototype and deploy in the knowledge that adjustments can be made so easily later, fundamentals such as fully understanding the user/business requirement, conducting good old fashioned data analysis, and building the application on a solid, structured foundation tend to lead to more robust and maintainable systems. This kind of feedback goes hand-in-hand with the findings from another piece of research highlighting that the reliability of software from an operational stability perspective is directly related to how early in the development process requirements such as resilience and availability are considered.

Much of this might appear to be common sense, particularly to those who have been around the block a time or two, but it does underline the need for balance between the freedom to rapidly undo, redo and adjust on the fly (the continuous prototyping and refinement approach), and the discipline required to deliver against the requirement first time – which users and business people care about the most. So be honest, if you or some of your colleagues have been seduced by languages and environments that almost encourage you make it up as you go along and see where it leads you, are you sure succumbing actually produces a better result? While no one is advocating a wholesale return to the strict waterfall approach, going too far in the other direction is a recipe for risk and inefficiency.

Lesson 3: Developers must be given the right tools for the job

Apart from the management issues discussed above, the other factor listed in the top three criteria for the perfect development environment was “Adequate investment in the right tools to do the job”, again with well over 80 per cent of respondents putting an emphasis on this.

When we drilled into this a little further, respondents pretty much universally highlighted the importance of a “Decent editing and debugging environment”, which came top of the list in terms of overall priorities. While it was pretty predictable that something so fundamental should stand out, it was interesting to see “Software configuration management” and “System testing tools” up there in second and third positions, with around 3 out of 4 poll respondents (higher in larger development shops) clearly regarding these as fundamental too. After this, opinions were much more fragmented on capabilities such as tools to help with requirements gathering, modelling and other more specialist management functions.

Important though the various types of tool might be, however, a significant shortfall in capability was evident across the board [View Chart]. While over half said their needs were fully met for editing and debugging, only one in five were fully satisfied with the functionality of their configuration management capability, and the gap was even larger (less than 15 per cent satisfied) when came to testing tools.

Do such shortfalls matter? Well yes, quite a bit, according to Reg readers. A direct correlation was evident between the level of tools capability reported by poll respondents and the overall performance claimed in terms of the development function delivering against business needs. Interestingly, similar correlations existed between capability and the desirability of the working environment from a developer perspective – i.e. developers’ lives are statistically better if they have the right tools.

We’ll be exploring some of these correlations in a bit more detail in subsequent articles, but in the meantime, there is a clear lesson here of need for tools investment to optimise results and maximise the delivery of business value.

Conclusion

There’s no shortage of developers telling us that there’s still plenty to be done – neither packages nor clouds have got in the way of the need for custom application development. While such a need may still be there however, what has come out of this poll is the need to strike a balance between formal and informal development approaches, driven by the fact that there are many different ways to deliver application functionality. To do this requires good use of management skills – particularly in terms of setting expectations and leading the dialogue between IT and the business. Tools can help – particularly those tools to help cut code as efficiently as possible, but also tools that add a level of structure and support the balance of approaches mentioned above, such as configuration management and project management software.

There’s plenty of noise in the blogosphere around new ways of doing things, particularly in terms of Web 2.0 and social networking – but nobody’s looking to throw out the baby with the bathwater just yet. ®