Home > Blogs > Two Analysis Schools

Two Analysis Schools

Over the years, I have seen two distinct analysis schools of thought. There is the 'let's get this over with so we can start doing the real work' school and the 'let's work through the tough problems now so that our implementation is straightforward' school. There appears to be a gradual migration from the first to the second in the industry, but the first continues to be fueled by a lack of appreciation for the value of effective analysis in the educational system.

For most of the early challenges we are presented when we are cutting our teeth in the software world, it is sufficient to place our emphasis on the implementation. The issues are of a magnitude that a few of us can handle them in a short period of time, without much struggle. The relative value of a deep understanding of the system is low, and so we can get by without strength in a range of analysis techniques, just as we can build backyard sheds without an understanding of critical architectural concepts. Indeed, spending too much time analyzing relatively trivial issues can tend to slow us down if we're not careful.

As we graduate to real-world issues, though, we often find that these brute-force implementation techniques won't scale. The challenges aren't quite as tidy, the complexity of the solution required increases dramatically, and the coordination of a diverse set of disciplines takes us beyond the skills we have applied in the past. If we try to tackle these more difficult issues without the benefit of deeper analysis, we can easily find ourselves up against a wall, as the complexity of the problem has overwhelmed us. Thinking about a complex problem from the code space can have as much merit as trying to deal with complex architectural issues from with a hammer in hand.

In some cases it can make sense to quickly capture what is known so that you can forge ahead with the implementation. An architectural spike in tan agile environment can get the team moving in the right direction, and progress (and deeper discovery) can be made quickly. Unfortunately, teams will sometimes head down this path when they don't have a) massive anticipated change, b) tight customer interaction or c) continued implementation based on a working system.

If we neglect effective analysis when there is not massive change, we have missed the opportunity to quickly grasp the whole problem and design an implementation that will get us efficiently to the end point. It is quite reasonable to be agile with systems that can submit to good analysis techniques. Contrary to what some teams appear to believe, agility is not synonymous with having your nose in the development environment all the time. When it is feasible, deep analysis towards a known solution is preferred over the risk mitigation through refactoring, just as refactoring is preferred over no analysis at all.

Analysis is the point where we have an opportunity to develop our vision of the solution based on the needs of the customer. If we're not engaged with the customer throughout the process, our analysis is likely to lead us down a path of building what we think the customer needs, often biased by our own technical knowledge rather than a true understanding of needs. We can easily make our software solution more difficult than it has to be without recognizing it. We may provide a solution, but overwhelm our customer with its complexity.

The greatest challenge that I have seen with good analysis is that there are so few people who are genuinely skilled in the wide range of techniques necessary to pull it off. Because of this, most 'analysis stages' that I have seen have been quite inefficient, with limited value. These phases are often little more than capturing what the customer said they wanted. Instead, this should be the starting point where the analyst models the system from a variety of perspectives, and uses these models for further discussion to refine a shared understanding. Rather than producing a requirements document (ugh), emphasis should be on understanding what needs to be built, and knowing that it really will meet the client needs.

With the notable exception of a few institutions (such as the University of Victoria locally), few software engineering or computer science programs provide their students more than a smattering of guidance on analysis. I know from whence I speak: I was the one that provided that smattering for 4th year students at a local college a few years ago. about 3 hours of focus on analysis was what they got in a 4-year degree program. Graduates take this lack of respect for the value of analysis, and often get jobs with companies that don't perform effective analysis, reinforcing their weaknesses rather than correcting them.

Change is rampant on many projects not because the problem domain is volatile, but because nobody has taken the time to understand it in the first place. For all the efficiency that is suggested by some in the agile community, I still argue that there can be better ways of understanding the problem domain than the code space. Embracing change does not mean we need to set ourselves up for massive change. Even with agility, many teams are making the problem harder than it has to be.

Fortunately, the industry is waking up to the importance of analysis on projects. The IIBA is a nascent organization that emphasizes the value of analysis, and certifies analysts in a manner similar to how the PMI certifies PMP's. This is a step in the right direction, even if there are caveats. As with PMP designations, certification in analysis skills should only be considered a learner's permit, not a certification that this person will be competent in the role in the real world. It is a recognition that a core terminology can be used, and there has been exposure to a range of skills. There is a requirement to have had experience in the analysis space before certification, which goes beyond some 'master level' certifications that exist.

It will be interesting to see how the struggle between these two forces plays out over time. While it would be great to see more educational institutes step up their emphasis on analysis, I'm not holding my breath. I've got more faith in the growth of professionalism in this discipline take hold on technology projects, and hope it can rise above the cacophony of quick-fix solutions and 'my approach is right' bandwagons. The industry needs to understand that for difficult challenges, effective and appropriate analysis can provide an effective basis for a strong solution.