|
| Featured Contents |
| Question of the Day |
| The Voice of the DBA |
Reducing the Cycle Time There are lots of software development methodologies. This page lists a few, among them waterfall, agile, iterative, rapid, and more. What's been interesting to me is that the process of deciding what to code and then whether it works doesn't change much between different ways of building software. Instead, the cycle time between when we ask a client what to do and when we deliver it changes. The more agile/lean we are, the lower the cycle time. The more waterfall-ish, the larger the cycle time. I guess that analysis and breakdown of problems into work also changes, as the scope in modern DevOps styles of development is smaller (more contained) than in waterfall. However, we seem to follow the same steps. In the database world, we might do similar things if we think about how we build data models and code systems. We could get all the requirements and build the entire model, or we could get some requirements in an area, build that, and then ask for more. The former is more of a waterfall approach and the latter more agile/DevOps-y. Is one better? Not really. I would say they are both situational. In some domains, waterfall might work better. When deciding to build a system to launch rockets, most of the problem domain is known and not changing often, so waterfall type approaches likely work well. Certainly we still went some level of decoupling to take advantage of changes that do occur, primarily in the hardware, but the overall problem remains the same. However, in many of the business or software tooling places I've worked, no one has a good grasp of the entire domain. Heck, I think in most businesses, people roughly know how business runs, but they forget the myriad of exceptions that ensure our environments look chaotic to software, and they often constantly refine (or re-direct) the way the business works in pursuit of their latest goals. At times I'm amazed business runs smoothly, though I think this just shows how much we tolerate variance in business processes that we think are more set and defined than they are in reality. I am a big believe in loose coupling and accepting uncertainty. I hope for the best, but plan for the worst, or at least, plan for things to change. I like NULLS in databases, not everywhere, but in places because have unknown values. I like agile/DevOps approaches to software because we rarely know all the information about a problem. Heck, sometimes clients don't know the entire problem or don't spend time thinking about the entire problem when they create requirements or requests for changes. Therefore, I like short cycle times, with the flexibility to change directions as necessary. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
| Featured Contents |
