How to Improve the Odds of Success in Software Development

Software development projects are notorious for having a high failure rate. within the context of this paper, “failure” is defined as, “not meeting the project sponsor’s expectation and/or stated requirements”. this is able to include such things as failure to function within the intended way as defined during a requirements document, not obtaining the specified performance standards, going thus far over budget that the project is canceled, or incurring numerous bugs that the end-users view the system as unusable.

I began programming business applications twenty-nine years ago. therein time I’ve worked as a systems support engineer, developer, solution architect, director of development, consultant, trainer, and CEO of a software company. What I’ve learned from these years of experience is that projects fail repeatedly for a really list of reasons. This paper will identify those key points of failure and offer simple guidance on the way to avoid them – I say simple because to adequately cover all of the ways to unravel software development problems takes volumes of books.

1 – Requirements

Many, if not most, companies have a explanation within the migration of their data storage, workflow, and reporting processes. the standard path of transformation is to travel from paper, to spreadsheet, to database, to stylish business application. During this transformation, which frequently occurs over a few years , the terminology and workflow process that were used when the business operated on paper often gets carried over to the spreadsheet. Business jargon and processes are established around how the business must operate under a paper-based system and continues after the corporate migrates to a spreadsheet-based system. This repeats itself again when adopting the database-based system, and so on.

The problem with this is often that when a corporation has finally matured to employing a fully capable business application for streamlining workflow processes, expanding the companies capabilities for analyzing and reporting on business data, that system’s full capability is never realized. this is often undue to the lack of the technology or the programmers creating it, it’s typically caused by the business not being properly analyzed when preparing the wants .

All too often, the interior sponsors of the project, end-users, business analysts, and other domain experts, are often in an excessive amount of of a time constraint to satisfy milestones imposed by a Project Manager or Business Manager. Thusly; the project misses a very golden opportunity to understand a way higher ROI on the system, greater productivity increases, longer lifetime of the system, and better suitability for the way the business currently operates.

Here’s how you would possibly resolve the problem:

Advise/enlighten the PM: Let the PM and therefore the project’s stakeholders know of the results of not evaluating the workflow process and domain terminology sufficiently.

Document the value of wanting to rewrite a system: A rewrite in just a few of years, or worse, never getting the system launched in the least , compared to the additional time to conduct a correct analysis must be reviewed during the initial planning of the project. Engage the business analyst and/or architect to assist with this as early within the process as possible.

Question conventional terminology. Create a dictionary of the domain’s “Ubiquitous Language”. Challenge each term and its aiming to each stakeholder, sponsor, or end-user. In other words, requirements gathering is quite just collecting nouns and verbs.

Work with a website Expert: a website expert – versus everyday end-users – can analyze business processes that require to enhance and the way the system can accommodate that. Don’t just assume the info set tells the entire story about how it’s used. The business analyst, or domain expert, must have a solid understanding of your business, not the technology to be wont to serve it. Again, this could be wiped out collaboration with the architect.

Create simple to know user stories: Good user stories are short, precise, and limited to single actions. they ought to clearly state who, what, and why for every action the end-user or the system must perform. Don’t create elaborate requirements documents that obscure the intent of the need – it is the old adage of, “can’t see the forest through the trees”.
2 – Translation of Requirements to Technical Specifications

The biggest “hat trick” in developing software is taking business concepts, which are often rather abstract in nature, then converting them into very literal, concrete technical specifications. repeatedly the context of the business processes are either not understood by the programmers or, not accurately translated into the technical specifications and ultimately into the code of the system.

The problem with this is often that you simply have business people producing the wants and technical people making that translation. Unless the technical person features a true understanding of your business and, its business concepts, then the interpretation will most frequently be wrong. Unlike translating two languages with Google translate, where an individual can guess at the meaning of words not translated correctly given a selected context of the conversation, a computer application cannot. Concepts, processes, actions all need to be very specific so as for the pc to process it.

Many development companies assign the task of creating this translation to programmers. this is often inherently flawed as programmers are handling the best details of coding instead of the upper level, abstractions found in business. Bridging this gap in concepts and level of detail is almost impossible to try to to well and, often time produces catastrophic failure within the project.

This is witnessed by observing the code and comparing it to the user stories. Often time the code combines multiple unrelated user stories into an equivalent file, making it about impossible to know , modify, extend, verify, or maintain.

Another observation is that the code are going to be missing complete concepts derived from the domain experts and can be accommodated by a lengthy little bit of code that works round the concept instead of articulates it. samples of this is able to be where there are well used, common terms of the business, which relates to either specific data or specific processes that are real-world things therein particular business domain. When reviewing the code, it’s common to ascertain none of those terms used, but instead, replaced with technical jargon, arbitrary abbreviations, or worse, single letters. This makes it difficult to impossible to understand if the code is actually matching the wants albeit the end-user functionality seems to be there and dealing , it doesn’t suggest the code was constructed properly. What this will cause – and nearly always does – is that there’s a high probability that while the primary iteration of the system might sound to figure fine, when the business wants to increase a feature’s capability or, add new features, the inspiration of the code just won’t support it. I cannot count the amount of times either I or other technologists have had to advise the client, “A rewrite is required”.

Most companies plan to solve this issue by including a business analyst and/or solution architect on the team.

The responsibility of the business analyst is to be a website expert and skills to properly document the wants of the system during a way that technical people can understand.

The role of the architect is to require the wants and model a system during a way that illustrates a transparent understanding of the wants to the project’s stakeholders and a transparent technical framework to figure within for the programmers – thus, the “hat trick”.

The problem with this is often that the majority companies consider an answer Architect as an individual who has been a senior programmer or technical team leader who, thanks to longevity (experience) must be promoted to architect because the next logical step. However, this just means we are back to the beginning of the matter with a programmer, albeit highly experienced, making the translations. Unless the business analyst did an outstanding job in articulating the wants in way that’s easy for programmers to know , there’s still likely to be the gap in concepts and understanding.

Rarely do senior technologists have a deep understanding of business concepts, and equally, business analysts a deep understanding of programming. What’s even more problematic is that programmers are almost never experienced during a domain enough to supply insight or suggestions into the way to improve the present business processes or way the business data is organized. They rely solely on the small print of the wants and don’t typically “think outside of the box”. this is often extremely common with offhshore development companies.

The one difficulty regarding this is often that it still takes a singular individual to really shine at being equally capable in understanding business concepts versus technical concepts. many of us operate with just one sort of thinking pattern, either they’re very detail-oriented, methodical thinkers, the sort that observe software programmers, accountants, and NASA engineers, or, they’re creative, abstract thinkers who observe architects, artists, financial analysts, and marketing professionals. The latter can more easily see things from different perspectives where the detailed-oriented must confirm all the dots are connected. it’s simply the altitude at which you view a drag .

Understanding broad business processes like customer relationship management, or supply chain management requires a much more abstract, imaginative sort of thinker than does determining the way to construct complex securities trading algorithms in code.

Unfortunately this is often a difficult problem to unravel as there aren’t tons of solution architects who have both a MSC and MBA in their education or, the hand-on business experience to reinforce their technical experience. However, this is often really what’s needed.

More info at

Leave a Reply

Your email address will not be published. Required fields are marked *