Our pursuit of a more effective, efficient SDLC is, in part, simply a function of basic curiosity and a desire to improve the world of software development. It is also perhaps an inevitable consequence of 30 years of experience across the wider SDLC, in both academic and practical contexts, including extensive experience in specific areas such as requirements engineering, business analysis, coding, and technical architecture. However, despite our making some good progress in this area, the same basic problems keep reoccurring, with the same consequence: a very suboptimal SDLC that all too often results in the delivery of inviable software products.
Of course, this problem is very well recognized, researched, and debated. Academia has covered this problem extensively, and there are many PhD theses on this topic. Likewise, many commercial organizations make a big point of promoting their unique ways of building software products. Welcome to the world of software-engineering methodology.
I subscribe to a belief that many people who solve complex problems share: If you truly understand a problem, you are probably 90% of the way toward solving it! This is why Part 1 of this series focuses on the key problems that we often experience in the SDLC. I’ll first address holistic SDLC problems, then discuss some specific issues in relation to the UX function.
Holistic SDLC Problems
A useful framework for discussing these problems is to consider the four big players in the software engineering methodology game today: waterfall, agile, Lean, and user-centered design (UCD). All four of these methodologies have sought the goal of improving the SDLC—and all four have brought both successes and problems.
Perhaps one of the key problems is that many professionals have simply not understood what these things actually are. They are frameworks, paradigms, broad approaches, or ways of thinking about the SDLC. They are not software-development methods and do not provide any detailed advice on how to actually build a software product. So, when an organization says, “We use agile,” that can mean many different things! Likewise, there are very few examples of organizations using any of these frameworks in their pure form. For example, many organizations chant the mantra of UCD, but even a cursory investigation reveals that their methods mostly fall far short of the true definition of UCD. In reality, most methods are unique, custom hybrids that incorporate some parts of some of these frameworks.
Waterfall
Waterfall’s concept of breaking big problems down into discrete stages is basically reasonable. Indeed, it is a necessity in my opinion. Its drive to create a holistic view of the software as soon as possible is also admirable. Accountants, lawyers, and technical architects love the illusion of certainty it brings. Of course, waterfall’s reality rarely matches anyone’s fantasy of what the final software will be. This is partly because requirements can never be fully defined at the outset. They often legitimately change during the SDLC, which is typically a long process, and the world often changes significantly during development. Plus, a lot of learning about the requirements takes place during the SDLC process. Indeed, much learning takes place precisely as a result of executing the SDLC.
However, many of waterfall’s failures are not a result of its core principles. Rather they occur primarily because of two of the more pragmatic features that people have historically associated with waterfall. The first is that most waterfall projects rely on abstract modeling devices such as requirements documents and use-case diagrams, which inevitably leads to high degrees of ambiguity in the definition of requirements. Second, most teams have chosen to structure waterfall projects so different teams carry out separate stages of the development process. For example, a completely different team from the Design team carries out the requirements stage, using fundamentally different tools and techniques. This inevitably leads to massive communication problems across the stages in the waterfall.
In reality, there is nothing stopping the use of concrete modeling devices on waterfall projects—such as interactive, high-fidelity prototypes. Likewise, it is perfectly feasible that the same team could carry out the requirements and design stages, using the same—or at least more similar—tools and techniques.
