Understanding the Differing Goals of Software Development
In preparation for a new series of articles which are forth coming on the different roles within software development, I stumbled across the uncharted territory of how different kinds of companies approach software development. During the process of preparing to discuss various software development roles, I realized that the team dynamics are very different between corporate developers, software company developers, and consulting developers. This article will help you understand the different objectives of software development within organizations.
Before we delve into the goals of each type of organization, it's important to understand that these are generalizations. There are some organizations that don't behave according to the norms that I describe here. The objective is simply to explore how different types of organizations typically have differing objectives and how some of those goals may be detrimental to the software development process.
Most developers have experience with the corporate development environment. This is because there are so many organizations with developers. If you're working for an insurance company, a manufacturing company, or a healthcare company, you are part of the world of the corporate developer - complete with all of its disjunctions.
In reality there are two kinds of corporations that take part in development: large organizations with structure and processes, and smaller organizations who are trying to develop software with few resources. Let's explore the process of development in a smaller corporation first.
The typical development situation for a smaller corporation is that there is very little support of the process from more senior staff or no routinely enforced software development practices. In smaller corporations, there is generally only one, two, or at most a handful of people who are taking part in the process of software development. The result is a great deal of inefficiency because the development needs are too great for the developers to handle. Although it varies from organization to organization, often times the necessary roles to support a developer are missing from the development process.
One of the ways that this problem shows up is in the lack of clearly defined, detailed requirements. We've learned that taking an organized approach to the development of software is the most efficient approach. Whether you're using a traditional waterfall method of software development or one of the newer, rapid application development methodologies, they all start with understanding the problem trying to be solved. However, because development is not a priority for the organization, there is no perceived need to optimize software development processes by defining clear requirements. It's easier for the business user to simply put together some rough requirements to get the developer started. From there, the developer begins to develop the software. When the program doesn't do exactly what was needed, the business user provides more definition. The developer makes the changes and demonstrates the new program to the internal group asking for the program. When it still doesn't meet the desired goal, the program is modified again and again. The result is a huge amount of effort used to develop a program that could have been simplified by developing clearly defined requirements.
In addition, there is generally a large amount of orphaned code which isn't properly removed from the solution in the rush to meet the needs of the internal customer. This leads into a downward spiral of maintainability problems as described in my article Fragile Code (link).
Another side effect of the corporate development mentality is that there is rarely appropriate project management control on the software development projects. This may start by the lack of clear requirements and move forward into issues around a failure to tightly control testing and acceptance. Normal changes during the course of the project are generally not well planed for or adapted to. Of course, this has the impact of not only increasing project cost, but frustration as well.
There are often few competitive market pressures and little time to set aside to support process improvement and learning. Standard software development techniques, such as object oriented development, are often not fully integrated into the development processes. In the long term, corporate software developers struggle to remain as effective as their peers. They find themselves suddenly laid off with a need to retool their skills before they can find their next position.
In larger corporations, the development process is more defined; however, there are still problems. The larger the organization, the more systems there are in production. As a result, there are more production problems which must be supported. In the larger organization, processing help desk tickets are routinely routed to developers for investigation and resolution. This practice not only prevents the addition of new features, but also creates a great deal of distraction, which is never good for software development.
On the whole, larger corporations have more bureaucracy than other types of organizations. Without market pressures within the IT space to drive bureaucracy out, it often grows within the IT organization to the point that it can immobilize even the best project. There are architecture groups to get the program approved by, steering committees setting the priority of various projects, and an endless array of middle managers who need to approve a project before it can even start.
From a goals and objectives standpoint, the objectives for a corporate developer of any size are generally focused around simplicity and the desire to make sure that the application can be maintained. Making the application maintainable refers to two things: being able to detect infrastructure issues; and future maintainability of the code by subsequent developers.
The final objective in most corporate organizations is getting the solution out as quickly as possible. There is always a long line of other projects behind the current project; therefore, getting the current project done is always followed closely by the next project on the list. Notice this objective is in direct conflict with the situations noted above, which cause the software development process to be ineffective and require more work to get the same set of deliverables accomplished.
The Software Development Company
Software development within a development company is much more progressive in comparison to other corporations. It does, however, have its own challenges.
By and large, software development companies are driven by the technologies the solution uses. An architecture group may have been a part of the large corporate developer's life, but at a software development company, the architecture group typically includes people at higher levels of the organization. The result is that the architecture hurdle is substantially larger in a software development company. Even a simple decision on architecture can take the form of a month's worth of meetings. Because the technology is perceived to be key to the value the organization contributes, it is given high regard - even to the point of becoming a "sacred cow" which developers know that they can't challenge.
Requirements at a software development company are some of the most rigid to be found in any type of software development. Because there are many clients to be satisfied, the requirements that a developer sees are the distilled requirements created from the various needs of the customers.
The rest of the software development artifacts are generally created from the detailed requirements. Detailed design documents are created to map back to the requirements document. Program specifications are created to ensure the programs being developed match both the requirements and the new design. This, in turn, leads to testing plans. All of these steps help to ensure projects are efficient and effective.
In a software development organization, there's generally more focus on having the right people to do all of the roles needed for successful software development. Because of this greater focus, project management control is generally higher than in a corporate development environment.
However, one of the challenges with software development in a software development company is that the processes, procedures, technologies, and techniques are generally more ingrained and, as a result, changes to the process are more fiercely contested, making integrating new process improvements more difficult to accomplish.
The final component of the software development company is that they typically have a system for measuring customer satisfaction with their products and facilitating the capture of that customer satisfaction rating system. This allows for a continuous feedback cycle designed to push the software development process to improve, despite the natural resistance to any kind of process change.
The Consulting Company Development
My home ground for the better part of my career has been within consulting companies of various types and sizes. While I've worked as a developer in a corporate environment, shared a beer with friends in both corporate environments and software development companies, my home is really in the consulting company.
Software development in a consulting organization is truly a different animal. Typically, a good consulting company will gather good requirements and will maintain appropriate project management control on the project. What gets interesting is how this impacts the projects.
Consulting companies typically focus on meeting the requirements document almost to the exclusion of all other factors. Although there are performance and reliability objectives in a project, they are constrained to the level at which the client is willing to pay. As a result, issues like performance and reliability are only approached to the point where they meet the criteria established in the contract or requirements. Where a software development company or corporate developer might seek to maximize reliability, performance, and flexibility to the best of their ability, a consulting company development project stops once the minimally acceptable level has been reached.
What the minimally acceptable level is for a given project is defined by the context of the organization requesting the project, the consulting organization, and what is written into the contract. Whatever the minimum is between all of these factors will be what the minimally acceptable values are.
However, because consulting organizations must remain flexible to integrate with the software development practices of a wide variety of organizations, they tend to be much more progressive in terms of adapting new software development practices into their process.
A place where the culture can diverge is in the development of reusable components. Consulting companies are faced with developing the same code over and over again for each client. Nearly every application needs code to talk to a database, present a user interface, manage a configuration, etc. In some consulting organizations, they get quite adept at copying or recreating code from one project to the next. In other organizations, a framework of base code is developed which can be used from one project to another.
In the latter case, it becomes easier to deliver true value to the end client because there's a large base of pre-tested code which can be used. This reduces the overall cost of creation and reflects the organization's investment in core technology.
The consulting company, like the software development company, typically has a customer feedback mechanism to help it understand the satisfaction of its customers and allow it to adapt to client needs and expectations. This system drives some of the process improvement that occurs in the organization.
On a parting note, it's important to note that the contractor - or contracting company - will adapt to their environment. The goals of the contractor may never perfectly line up with the organization's needs; however, they will often take on the same basic characteristics of the existing culture of the organization. Because of this, contractors should really be thought of as an extension of your software development process - for better or for worse.
About the AuthorRobert Bogue, MCSE (NT4/W2K), MCSA, A+, Network+, Server+, I-Net+, IT Project+, E-Biz+, CDIA+ has contributed to more than 100 book projects and numerous other publishing projects. He writes on topics from networking and certification to Microsoft applications and business needs. Robert is a strategic consultant for Crowe Chizek in Indianapolis. Some of Robert's more recent books are Mobilize Yourself!: The Microsoft Guide to Mobile Technology, Server+ Training Kit, and MCSA Training Guide (70-218): Managing a Windows 2000 Network. You can reach Robert at Robert.Bogue@CroweChizek.com.