Slashdot Mirror
Ask Slashdot: Has Your Team Ever Succumbed To Hype Driven Development? (daftcode.pl)
marekkirejczyk, the VP of Engineering at development shop Daftcode, shares a warning about hype-driven development:
Someone reads a blog post, it's trending on Twitter, and we just came back from a conference where there was a great talk about it. Soon after, the team starts using this new shiny technology (or software architecture design paradigm), but instead of going faster (as promised) and building a better product, they get into trouble. They slow down, get demotivated, have problems delivering the next working version to production.
Describing behind-schedule teams that "just need a few more days to sort it all out," he blames all the hype surrounding React.js, microservices, NoSQL, and that "Test-Driven Development Is Dead" blog post by Ruby on Rails creator David Heinemeier Hansson. ("The list goes on and on... The root of all evil seems to be social media.") Does all this sound familiar to any Slashdot readers? Has your team ever succumbed to hype-driven development?
Describing behind-schedule teams that "just need a few more days to sort it all out," he blames all the hype surrounding React.js, microservices, NoSQL, and that "Test-Driven Development Is Dead" blog post by Ruby on Rails creator David Heinemeier Hansson. ("The list goes on and on... The root of all evil seems to be social media.") Does all this sound familiar to any Slashdot readers? Has your team ever succumbed to hype-driven development?
I think infinite web pages was the worst idea that every site just had to copy to be part of the fad. I liked page number buttons. I can bookmark a page where I left off instead of scrolling a hundred times from the top again. It also doesn't use up all my computer's memory in Firefox or Chrome.
Main issue isn't "following the hype" -- it's not understanding why something worked for someone, or even why what you're currently doing is or isn't working before making sweeping changes.
PHBs making stupid and declarations based on trade magazines that sinks the project? Probably never understood what his subordinates were actually doing in the first place.
Developers changing languages mid-project? Forgot to add the time to master the language to the estimate, most likely.
For some projects and some teams, Agile is the best they can be expected to do. For other types of projects and other types of teams, it's a really horrible idea.
Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system. As Yogi Beara said, "if you don't know where you're going, you not get there." On small projects it might not hurt too much to figure it out as you go along, to backtrack and throw away code that has to be replaced. On large projects, and systems that need to integrate with other systems, you REALLY do need to figure out the requirements ahead of time and plan the architecture.
If your team consists solely of programmers of medium competence, Agile may be the best choice. If you have even one excellent systems architect, you're far better off letting therm do their job, planning the system out first. If your team includes junior programmers (or veterans who haven't expanded their skill set over the years), Agile can leave them floundering, going one direction for a few weeks, then another direction for a few weeks, then completely backtracking for a few weeks.
In summary, Agile is sometimes the best choice for your team, and when it is, you've done a poor job of hiring.
Several years ago my Pointy-haired Boss was reading technology articles (bad idea) and caught the "Big Data" bug. It spread to our CTO, CIO and all department heads like wildfire. This led to our Development team being turned into NoSQL zombies who said words like "Hadoop", "Shark", "Spark" in response to any new product requirement. It was a glorious vision of a magical backend system that would take all our data from every platform, that would scale up and out forever, and could be asked any question and give us exactly the results we wanted all instantly. The fact no one in the entire company had ever used any of the technology before or the fact we didn't even have any Java experience to setup even the base Hadoop installation were just minor points not worth discussing. I would like to say I was the lone dissenting voice, well I was and said lets just stick to SQL, but even I got caught up in the hype eventually.
18 months later and a sickening amount of man-years wasted and contractor money spent with no usable products or services the conclusion was NoSQL isn't a good fit for our data or platform use case. So they all went back to standard MySQL and completed 90% of the delayed projects in under 4 weeks.
On the plus side management heads did roll. I have a new My Pointy-haired Boss and CTO. However they have now started to drop in the words "Microservices" and "Docker" into all discussions. I can see a new hype-train arriving shortly ...
The problem is that people want magic solutions, and they keep chasing the latest fad in the hopes of finding the secret alchemy that will make average developers turn into gold stars, produce perfect systems in a tenth the time, and meet all requirements without the bother of knowing them.
Anyone who's ever done any system of significance that actually worked will know that the "best" tools and methods are situational. Need a bash script to list a few files? The approach is different than it would be if you're hired to redo everything used by the IRS.
We can go all the way back to the "shelf full of binders" methodologies. In their day, they were supposed to be the magic cure-all. Today, it's Agile, or it's XYZZY or whatever is the latest and greatest. Still haven't found that secret sauce.
One size doesn't fit all. There is no magic. Successful development projects require skill, experience, good judgment, hard work, and competent leadership.
Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system.
The problem is that waterfall is presented as making extreme effort to try figuring it all out up front, while Agile then becomes to the exact opposite where you make no effort and just prioritize what's right in front of your nose. Reality is that you need some flexibility in waterfall projects and some structure in agile projects. In my opinion it's fine as a development method, it's all the people making requirements who don't even try anymore because agile. We're so dynamic, as long as we can spin in place it doesn't matter that we're not going anywhere.
Live today, because you never know what tomorrow brings
I agree. I cannot wait for that fad to die an ugly painful death. Make the pages longer, that's fine. But not infinity.
I hear it causes ADA lawsuits. I hope so, sue 'em hard!
Similar annoyance points for the "flat" look. You cannot even tell a button is a button, and entry box boundaries are washed out. Shade the fsckers, people! It's not 1989.
Table-ized A.I.
The No True Agile fallacy.