JavaThe Great Divide

The Great Divide

Staring at the Grand Canyon in Arizona might make you think about how two worlds that are so close together can be so far apart. The distance from one side to the other may be only a few miles wide, but it’s also a distance that prevents most crossings. What we might be able to cover in our cars on a paved road in five minutes or less can take days on the back of a mule.

In software development, we have our own Grand Canyon – our own Great Divide. It’s not a divide between the “haves” and the “have nots.” It’s the divide between those who know, understand, and implement the kinds of things that we’ve learned about software development for the last 30 years – and those who do not.

I was reminded of this great divide last week as I approached several clients with their own perspectives on software development. Each situation was different, but the clients fell into two distinct categories. Looking back, I suppose that all clients eventually fall into one of these two categories, but never was it so clear as when they confronted me back-to-back.

The first of the two categories in the software development world involves those that are committed to doing what they know is right. They read industry journals, books, and magazines to learn of new techniques. They also retool their knowledge to apply traditional software development knowledge to new technologies.

The other category of software development team is stuck in a time warp where they do things as they have always been done. They don’t attend local software development users groups and they don’t seek outside assistance. They don’t buy prepackaged software and adapt it. They hold on to the mistaken impression that their business has the monopoly on what they do. For that reason, because they believe that they are the only ones in the world doing something a certain way, no software package could ever capture what their needs are.

Having said this, I’ve occasionally run into the organization that really does have a unique value proposition, which means that standardized software won’t work well for them. One example is a computer recycling organization that takes in computers as they are retired from corporations, refurbishes them, and sells them to other organizations or consumers. Their inventory problems are substantially different than what is offered by any of the standard packages that are available today.

However, in most organizations, the problems are not materially different than in any other similar business. You may have your own unique view of the problem and your own unique value proposition; however, for the most part, there is probably a solution that will meet your needs.

Buy, not Build

One of the biggest mistakes that a software development group can make is to believe that they must build software that they could buy and adapt. In today’s world, it can also mean the failure to purchase a toolkit that contains the base functionality that is needed because it is too expensive, because it doesn’t contain all of the features that are needed, or simply because it’s unknown.

When evaluating a purchase decision for a tool or package, the immediate thought in most software development professionals’ minds is the amount of time it would take to replicate the necessary functionality. This is the wrong way to view the problem.

The problem must be viewed from the perspective of the ongoing development and maintenance needs of the system or toolkit. A very small percentage of the lifetime cost of a software development project is expressed in the development of the software. Substantially more cost is incurred in the maintenance phase of the software lifecycle than in all of the other phases combined. In addition, testing can sometimes take up more time in the software development lifecycle than development.

It should be clear that software development is an expensive task. The sheer amount of labor to create anything – even with the best developers – should be avoided if at all possible. Buying solutions and adapting them, as little as possible, is almost always a good solution. Failing the ability to buy a prepackaged solution, consideration should be given to buying a prepackaged tool.

Prepackaged tools, or frameworks, simplify the development process by allowing you to focus on the things that are unique to your business, instead of coding the same credit card processing or some other standard piece of logic that others have already designed, built, and tested.

Project Management is Important

In many organizations, the professional discipline of project management has not yet been unleashed. Project management is essentially the process of keeping things on track by following practices and approaches that have been demonstrated to work over time.

In the software development world, we know that we must gather requirements before creating a design (or while creating a design). We also know that we cannot begin coding before the design is done – or at least partially done. We know these things as a software development community but, all too often, software is developed without fully understanding the requirements and without a solid design foundation.

When we don’t follow the proven course of software development, the result is dependent upon the skill of the developer and the size of the project. If the project size is small or the developer is very good, then it is likely the project will succeed, whether a known process is followed or not. However, as the project increases with size or complexity, it becomes exponentially harder to succeed without project management assistance.

Learn, Don’t Languish

At this point, give yourself some credit. Your decision to read this article is one way that you’re making learning about software development a priority. You’ve made your decision to be a part of the “haves” who are able to adapt to changing software development climates. You’ve made the decision to learn and perfect your craft. The key to this decision is simply to expose yourself to ways that you can improve your ability to develop software. Reading books and articles is an important part of exposing yourself to learning.

Participating in users groups or in online forums is also important to your learning and growth. Listening to other points of view is a good way to challenge your own thinking about the way that things should be done. Challenging your own thinking is essential to your growth.

Too many organizations are filled with staff members who are incapable of learning new technologies, techniques, or processes. They never have a software development magazine lying on their desk. Nor do they attend users groups or interact with any developers beyond the walls of the organization. This nearly guarantees that the entire organization will suffer from a lack of “idea diversity.” Similar to genetic diversity, “idea diversity” is required for long term viability.

Without employees who bring this to the table, consultants are brought in or turnover increases. The organization is forced to get some new thinking into the software development group for its own survival.


You’ve got a challenge. You need to help your organization develop the habits mentioned above, and dozens of others that will help to promote a world class software development team. Let me know how you’re doing at it.

About the Author

Robert 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

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories