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
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
Voice of the DBA 
Loosely coupled is the only way to re-create digitally how things work in the real world. Outside of software, re-use is highly encouraged where as in software it’s less so and IMHO a lot less so. An automobile is as reliable as it is because each part has been made to be optimally priced and optimally functional for it’s task/role. If you are a new or existing automobile manufacturer you’re not going to reinvent tire technology but are going to go with whatever existing tried/tested/true set of tires works for the car at hand. In software if you are creating something like an accounting software system for a specific industry I’ve seen more than one lead/higher-up do everything including re-creating existing applications solely b/c they didn’t want to license an existing piece of software. I first learned via C++ so I came into this from an OOP perspective and as the years went on I was shocked at hos often the tire had been reinvented for a wide variety of tasks all b/c no one wanted to pay anyone else. It;s also always irked me how Microsoft doesn’t take the de-coupling serious with their office products. There use to be a media player called WinAmp that was kind of unique in that the UI was so decoupled from the inner workings that any image could be the UI. I get from a help desk perspective why it can be beneficial that all users of some app have the same UI but that’s not the case with the office products. Had MS decoupled the UI from the app itself then when that Ribbon fiasco incident blew up, when they started forcing people to switch from menu/toolbar to the Ribbon, they could have avoided al of that b/c a decoupled Word or Excel would let the user decided Classic menus or ribbon. I worked with a video game Company (Ubisoft) on a title and had similar complaints with how the video games UI was so tightly coupled to the rest of teh game that changes that would have otherwise been simple are made much more difficult. I was told by a low level dev (off the record) that this was done this way b/c the other would have required more time and resources. What Ubisoft did was they ended up spending more $$ in teh end b/c they eventually had to go back and re-do some of the UI so any resources they saved on the front end by not de-coupling the UI was lost. It would be one thing if this was the 1st time this happened but it was a sequel in an existing IP and they had already had to do this in the IP’s prior title so it’s not like as if they had no clue a major UI change might be required post-release. All that said both models are needed b/c no one solution works for everything,. IN some cases the waterfall approach is better and in others it’s the newer cyclical style of DevOps. What’s most important is to never discard a tool or solution just b/c there’s something newer. Even if better there may be scenarios when it;s not better after all. My Step-father who was an automobile mechanic for 40+ years always said that you should always try to expand your toolbox tossing tools only once they are broken and unrepairable.
LikeLike