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?
about Black Belt training?
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.
The problem is that experience can do one of two things to developers. Open your mind or close your mind. Many programmers refuse to open the Pandora's box and they stick to a tool, paradigm or coding style they know even though its not the best thing to solve the problem at hand. It's like a carpenter trying to cut down a tree with a circular saw because that's what he spends 99% of his time using.
Wow, ExtJS brought all development to a complete multi year halt. In the first few months ExtJS development is way way way faster than any other framework out there. But after about 6 months all you are doing is fighting with the framework. Just an endless knifefight. Any single problem could be solved against the base instlall of ExtJS but what happens is that you have to develop workaround after workaround to make the system snap into place for any given need. Those workarounds then make future "easy" changes impossibly hard.
So you might have something as simple as wanting to put the focus on a login username. If you had just done the page as your first round and thought of that then, like everything with ExtJS, a little weird but fairly easy. If you already have fought with sencha to make other things happen on the login page (say a filtered twitter feed) then ExtJS is probably broken 8 ways from sunday and you can't set a focus worth a damn.
Save yourself a world of pain and just use basic javascript combined with either simple single function libraries, or worst case scenario use a framework that won't blow up your company like react or polymer. Yes, you won't be a showoff in the first few weeks of development like you could with ExtJS, but you won't blow up your company when you can't finish the project until you realize that it can only be done by throwing out ExtJS.And if you get 5 or 6 people in the company who get training by ExtJS, good luck cutting through her bullshit about how ExtJS is the best thing ever even though the project is now 18 months late.
When Agile fails, it is almost always due to the implementation NOT actually being agile. There is such a deep belief by many old-timers that Waterfall is the only way to get things done, that many simply cannot make the transition.
This is all proponents of Agile ever say. A noun a verb and "Your doing it wrong".
It's not a religious war. It can be and has been a disastrous waste of time, money, and life for many, many people. While Agile works well for certain types of projects, it does not work well for others. Choose what you like, I suppose, but all the market can reveal is that people who become enraptured by process rather than product are building castles on sand.
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.
> There's nothing preventing you from running an agile project with a robust and complete design.
A large project with a complete design, an actual plan, may be agile (the adjective), but it's very much not Agile (the development methodology). A core tenet of Agile is that design, planning ahead to the end of a project, is impossible. In fairness, it probably IS impossible, for the people who believe that.
If they haven't been taught one particular trick, they probably never will be able to know the requirements before they write the code - trial and error really is the only option, if nobody ever told you the method to find out the real requirements.
If you want to know what the actual requirements are, there's one way to find out (and maybe ONLY one way). Sit down with the user and watch them work. Ask questions as needed to understand their workflow while they actually do it, and take notes. Ask the actual user, not their manager's manager, what they need to do their actual daily tasks. That way, (and probably only that way), your User Stories aren't fictional stories imagined by some manager, they are real descriptions of real users doing real work. Requirements flow directly from there.
I disagree.
The experienced developer has been chopping down trees for years with an axe. He's been putting up shelves with a drill. he's been cutting floorboards with a circular saw. And occasionally he's been cursing because he's having to make do with the wrong tool because although he knows what the right tool is, paying $lots for a tool he will use just once can't be justified.
Alongside that there are countless (less experienced) developers suggesting that he uses the circular saw to cut down the tree, the axe to put up the shelf, the drill to cut the floorboard and the experienced developer isn't particularly impressed.
But in the back of his mind he's always got that thought "what if that next tool is the chainsaw. " Just think how many trees I could cut down then. But even when the chainsaw comes along, he continues to use the circular saw on the floorboards, the drill for the shelves and, indeed, he may even still use the axe from time to time.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
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.
Reading Slashdot comments it seems that many seasoned developers are dismissive of some pretty good new tech, even after it's been around for much longer than 5 years.
C# is a great example. I'm a hard core C coder who mostly works on embedded systems, but when I need to do anything desktop I always consider C#. It might not be the most efficient language, but it's performance is perfectly adequate for a huge number of tasks, it has libraries that simplify most day-to-day stuff greatly and lets you concentrate on structure and architecture instead of details.
People around here often dismiss it because of the association with .NET (which itself is far from terrible) and the fact that it hides a lot of the "real CS" stuff, but that's the point of it.
Save the hate for stuff that deserves it, like Javascript.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
People around here hate C# (those that do) because it's from MS. When it comes to MS, there are no technical merits that can redeem the technology. They are not rational people. Most of them probably don't even program for a living.