It is not magic. Building a successful IT solution takes time. And that time is used in various ways: obtaining an understanding of the goal; mapping out what components are necessary and how those components interact; testing components and their interaction; and finally migrating those components into the production environment - otherwise known as analysis, design, development, testing, and deployment. Regardless of the methodology employed, these functions must always be addressed. Different approaches focus on differing needs and aspects. But any complete methodology must fill in all the blanks for accomplishing each of these tasks.
Methodologies and their application seem to confuse some. Occasionally, individuals look down their noses at a "waterfall" approach, complaining about the length of the development cycles, simultaneously embracing agile approaches yet not acknowledging any need for or allowing time for refactoring. "One and done" is not an aspect of agility; and while "waterfall" is a dirty word, apparently the intended outcomes of that type of approach are still desired.
One symptom of an incomplete methodology is evidenced in situations where user acceptance testing becomes the primary means to gather requirements. Worse circumstances occur where requirements seem forever to be refined, altered, and restated. Incomplete methodologies also result in incomplete solutions, or ones that are constantly re-opened and ultimately become a black hole for organizational resources.
Another crisis of faith, apparent within IT development, concerns an ongoing belief held by some managers, executives, and even stakeholders that everything revolves solely around coding. Yes, coding is a lot of fun. Ask developers, coding is what they enjoy. And certainly the code can be considered the most important deliverable. However, jumping right into the code is like starting to run before you have learned what direction the finish line is in. While IT development can be (and often is) done that way, the consequence is constant reworking, redoing, and recoding as directions keep changing, while still probing for that finish line. The first expected efforts can only be heaps of code and tables. Even when not distinguished as a distinct step, design must happen. If design is only allowed during the coding process, there should be little reasonable expectation of reuse and clean interactions. A design evolved in this fashion is likely to remain crippled in one place or another throughout the life of the solution, however long or short. What is often forgotten is that coding is only a part of the whole effort; coding is not and should not be considered the entirety of the effort.
- How much time is saved in doing things properly? Any time saving largely depends on many factors, including the following:
- How well does your team already understand the business?
- How long will it take them to understand the parts they still need to learn?
- How well defined are the SDLC artifacts to be delivered?
- How well understood is each person's role on the team?
- How understood and accepted are the interactions between roles on the team?
Confusion over this preceding list of factors is responsible for a large percentage of delays on many initiatives. Simply crafting a process that addresses the basics, actually informing staff of that process, and then following through on having people adhere to the process can greatly speed up delivery and improve the quality of the final solution. Once a thorough methodology is in place everyone on the team should be able to see the finish line and work through their responsibilities as quickly as possible. The ultimate goals are delivering quality results, optimizing resources, and providing managerial controls. Having a consistent development approach improves estimating future efforts. Everyone ends up a winner.