Software development gets real

Building good software requires people and processes that are flexible and know how to adapt to unplanned requirements. E&T looks at the top three software engineering challenges, and explains how Software Configuration Management lends a helping hand.

Software has become immensely complex, and yet at the same time we demand more of it. As business requirements change, the corporate technology backbone must be flexible enough to bend to the need, or profitability gains will slip. New software implementations are deemed a panacea, but businesses too often fail to think through the full lifecycle management implications of project deployment.

There is a way to address this issue. The objective of Software Configuration Management (SCM) is to track and manage changes, and to store and recover arbitrary collections of files that make up the deliverables of a software engineering project. SCM is often implemented around what the business needs going forward; so, crucial to the long-term success of SCM roll-out is an appreciation of which factors will affect software development as we know it.

One of the reasons why flexible SCM controls need to be set in commercial environments is that, once a software application has reached final stage roll-out the developers bringing the product to market will want to capitalise on it, and spawn variants. Consumers demand choice, and software is as subject to this reality as any other product. Choice demands change - and change demands management if it is to be executed properly.

"Placing your faith in re-architected software without an SCM layer is a bit like emigrating to Tibet without a phrasebook," says Duncan Chapple, at analyst relations consultancy Lighthouse AR. "It might work, you might get lucky - but it's far from guaranteed."

Given today's needs for IT governance, security, intellectual property controls and shareholder accountability, Chapple feels that SCM can play a vital role in ultra-dynamic software development environments, and is a prudent consideration even in more static deployments. At the very least, some type of version control system should be in place to boost internal data knowledge and aid flexibility when the need naturally arises."

Across every industry sector, software programmers, system architects, project leaders, and team members using other technology will all be familiar with the term 'project skew'. It is rare for any project to hit its original target, and it is rarer for any target to remain in one place for long. SCM, in practice, has proved beneficial in three key areas of commercial reality.

Pressure point 1: Software never sleeps

As the technology industry continues to expand, so does the global network of software programmers that can input to projects at any one time. Maintaining an accurate holistic view of what's going on in a project at any point across a globally-distributed team is a major challenge - and one that is increasing all the time.

Western Europe dovetails nicely with Australia and New Zealand, while California aligns similarly to share a 12-hour time difference with Bangalore in India. These international tag-teams work on initial project builds, but also handle ongoing support and maintenance.

This means that development teams in any location must be able to work against a live, communal repository holding all project files and metadata that can be accessed at any time. So, a 'nine-to-five' development shop, with overnight builds, doesn't work any more. The bedrock of an SCM layer will focus on facilitating control, reporting, and collaboration. It's fairly straightforward to see why these elements will be important in an environment with language, time, and culture differences, but where a common end goal is shared.

Pressure point 2: A holistic view of the long-term goal

Tracking and managing all of a software project's digital assets from source code to supporting documents, graphics, and video can be a mammoth task, much prone to error. This becomes tougher once variant versions are called for; and it becomes tougher still once elements of the project are outsourced and returned as 'code drops' - meaning that chunks of new development will hit the central data repository, and be expected to function correctly first time.

The reality is that an inherent lack of control develops once the total ability to manage the project goes out of your premises. If elements of an outsourced project are late, you have to be able to deal with the situation, and work with an adaptable management tool that can help take control. Going further still, different members of the company will want to be able to extract different information at any time, so you need to be able to give control to both individual developers and programmers - at the same time as you offer it to management.

This is no small task if outsourcing is also brought into play, so maintaining a holistic view of the long-term project goal is crucial. Keeping site of that goal and still delivering a quality product without using a SCM-driven approach is a tough proposition.

Pressure point 3: Hitting a moving target

Technology pundits are fond of using the term 'nimble' when referring to the flexibility that must exist in a modern application development environment. Building a software 'shop' that is capable of taking advantage of new opportunities may mean tackling the concurrent development of multiple codelines. If this is to produce a bug-free product and the team is to adhere to best practices throughout, then they will need to be able to automate repetitive development tasks where possible. This is where SCM can 'sell itself' to the programming team who can be reluctant to engage with reporting tools unless they fail to see the direct benefits they can derive from them.

"SCM is a broad discipline that requires a range of tools to handle heavy duty tasks including version control and code sharing," says Bob Tarzey, service director at analyst house Quocirca. "No software engineering project should be run without at least the core elements of SCM in place."

Tarzey points out that it is, after all, possible to develop very good software that is of no real use to the business, so a requirements analysis tool layer should be considered to work alongside a basic SCM implementation: "SCM should be deployed on any software development project, be it a business application, an aircraft control system or even in games development - where free thinking and creativity are positively encouraged, but core controls still need to be in place."

Get the recipe right

Ensuring that 'baked-in' flexibility is present from the start of a software project comes only from an initial architecture that has embedded controls in place to manage a central repository of knowledge on core application functionality.

After all, software - and, crucially, the information, data, and intellectual property that it controls - is a central asset of corporate fixed capital, and more CTOs are now increasingly acting as influential board members.

Some companies refer to SCM as a kind of 'corporate memory' system because all data files - however they were produced - are kept in one easy-to-navigate area. Because there is always a cause and effect relationship between factors that may influence a software system change, an SCM tool can be used to discover what has affected what.

Software system scrutiny

Whether or not you are a technology practitioner, it is interesting for business professionals in all disciplines to have knowledge of which performance aspects of the corporate technology resource pool (including the SCM system) need to be evaluated for effectiveness. A good basic checklist to keep in mind is usability, scalability, strength of the model and reliability. If those aspects are not immediately apparent, you may have a problem.

For usability, you need to examine whether your system is fast enough and capable of tolerating heterogeneous computing environments with different operating systems, different languages, or even different Web browsers. For scalability, if you acquire a company and have to double your Web presence overnight, can your system handle it? For strength of model, examine whether your SCM system can manage multiple, concurrent development and release codelines while keeping track of what bug fixes were made - and where. Finally, reliability: do your IT tools actually work the way they are supposed to - and will they actually be used?

Over the next decade software will have an ever-more important role in all aspects of business as it drives and empowers processes, services, and systems at just about every level. Its impact will exceed that of other aspects of IT deployment, such as processing devices, storage, connectivity, and other previously hardware-related challenges.

If software deployments are to be fully successful they will need to be super-flexible, they will need to embrace concurrent development streams, they will need to deliver for spiralling customer expectations and they will need to stay working 24/7, and be robust. To achieve all these things with the occasionally haphazard approach we have seen used so many times up until now will not be possible without embracing better software control and management.

Will SCM provide all the answers and solve all our problems? Probably not.

Will it help us move in the right direction? Almost certainly yes.

Dave Robertson is director of European operations for Perforce Software - [new window].

Further information: [new window] [new window]

Recent articles

Info Message

Our sites use cookies to support some functionality, and to collect anonymous user data.

Learn more about IET cookies and how to control them