Ask Slashdot: Has Your Team Ever Succumbed To Hype Driven Development? (daftcode.pl) 332
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?
Has the lord and savior told you (Score:2, Insightful)
about Black Belt training?
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Infinite web pages (Score:5, Insightful)
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.
And flat look [Re:Infinite web pages] (Score:5, Insightful)
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.
Re: (Score:2)
None of that is mutually exclusive with infinite scrolling websites.
Re: (Score:3)
Re: (Score:3)
I wanted to get in contact with one place who used an infinite page but they put the link to the contact information at the bottom of the page. So every time I scrolled to the bottom it would load the next section before I could click on the link.
Re: (Score:2)
Re:Infinite web pages (Score:5, Insightful)
NewEra (Score:2)
Many years ago I was working at a small company with about a half-dozen other programmers. We were all doing Informix 4GL and ESQL/C except for this one guy that kept to himself and never talked to anyone.
He was working on their next big thing - converting all the code to Informix NewEra or as some of us mockingly called it "New Error".
I left that place like a rat leaving a sinking ship so I'm not sure what ever became of them, but I'm pretty sure the NewEra product was never installed at any client site.
Happens a lot (Score:5, Insightful)
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.
Re: (Score:3)
"We are smarter than other shops, so we will cut all the developer estimates by half" -- actual thing said to me by an actual head of engineering.
Re: (Score:3)
That's why in my previous job I always tripled my estimates and made sure that my colleagues make so too.
Re: (Score:2)
Indeed - such as implementing the Toyota method without the feedback steps that made it work for Toyota (and Ford before that). That is a very common failure. Just about anything with "quality" in it's name outside of production line testing seems to make that sort of mistake too and diverge far from reality. A former
Re: (Score:3)
Agile (Score:4, Informative)
Re: (Score:3)
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.
I worked for a company that uses Agile (Scrum), but then acquired a Waterfall shop. By all accounts, the Agile team ran circles around the Waterfall team. The Waterfall team struggled to switch to agile, but not yet successfully. It's not easy to do, and the transition is often d
Re:Agile (Score:5, Insightful)
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".
Re: (Score:2)
Yes, I agree with you. I have seen it done right, and I've seen it done wrong, numerous times. It's a religious war, I know, and I know I won't convince you. But that's OK, I'm quite happy to let the market decide. As for me, I will always choose to work in an Agile shop. I'll take on your Waterfall shop any day.
Re:Agile (Score:4, Insightful)
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.
Re: (Score:3)
It's not a religious war. It can be and has been a disastrous waste of time, money, and life for many, many people.
Wait a minute, are you implying that religious wars are not a disastrous waste of time, money, and life?
Re: (Score:3, Interesting)
Re:Agile (Score:5, Funny)
The No True Agile fallacy.
Re: (Score:2)
Perhaps under the right conditions it can work, but it's difficult to get and maintain those right conditions.
Most organizations are a chaos of re-orgs, management re-shuffling, mergers, splits, etc. such that a "clean" environment is hard to come by.
It's like threading a needle riding a roller coaster. Stability may be asking too much. Come up with methodologies that can tolerate some grit in the gears.
Re: (Score:3)
I mean why lose two years work when a months or better still two weeks would have done just as well
Agile is good for some teams & projects, horri (Score:5, Interesting)
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.
Re:Agile is good for some teams & projects, ho (Score:5, Interesting)
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.
Re: (Score:2)
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.
Garbage, you simply show your ignorance. You know what? Agile is a meaningless term, you have some kind of image in your head of what it is (maybe informed by some group of idiots claiming to do it), and hence you can build this lovely strawman to set fire to. Here is the agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, whi
Re: Agile is good for some teams & projects, h (Score:2)
Zed A. Shaw pithily translated what Agilistas really mean when they claim to value those things.
Not that I endorse the idea of just "doing programming" as an alternative to understanding the project's needs, the team's capabilities, and using a process that fits both.
Re: (Score:2)
I disagree. Working at a primarily waterfall based company we have lots of change orders after systems go into production and as long as the code was designed well there really isn't an issue with adding new features. Sure, there are occasionally the huge changes that some customer decided they couldn't live without, but those types of changes hurt agile shops too. The problem you describe and "solve" is designing overly rigid code, not "agile is better than waterfall."
Re: (Score:2)
We agree about the importance of well-designed code. Poorly designed code hampers agile development as much as it does waterfall development.
My comments were about the requirements. Waterfall pretends to know the requirements up front, but then has to follow the project with a series of change orders. This happens because users often don't really know what they want until they see something in action. "Yes, this is good, but..." Because the change requests can't happen until the project is complete, they ar
Re: (Score:2)
Agile doesn't say you can't have big goals, only that the details can't be fully known up front.
The devil is in the details.
Re: (Score:3)
Exactly! So when waterfall tries to nail down the details up front, it does itself a disservice. Users find out months later that those nailed-down details don't quite work for them, and now you have to go back and re-engineer your project. With Agile, you find out much earlier in the process that the details weren't right.
Re: (Score:2)
There's nothing preventing you from running an agile project with a robust and complete design. Agility allows you to pivot if and when required.
The easiest way to think of agile projects is a series of really small waterfall-like mini-projects that deliver a working product at the end. As you complete each mini-project, your product comprises a larger set of features. When your feature set reaches MVP, you can release or continue iterating to complete more features, but you can feasibly release at th
It might be agile, but it's not Agile (Score:4, Insightful)
> 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.
Re: (Score:2)
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.
I'm so glad you're here as an obvious expert on all things software development process to explain Agile in such detail. It's so comforting to have a real professional help all us struggling dolts see why we've been getting it so wrong! I don't give two shits how you like to run your projects, but maybe you should stick to talking about things you know something about eh?
Re: (Score:2)
"pivot" == "we fucked up, start over"
Re: (Score:2)
ALL projects benefit from measuring the outcomes of small, incremental changes
Not all. You can't jump a chasm in several small jumps.
and continually finding and limiting waste
No process I can think of accumulates more waste than Agile, with half-written features that went nowhere, hooks for removed features, and features that belong together chopped up into ineffective pieces with extra interfacing in order to get one piece done in a sprint. It begets bloat, but that isn't necessarily a problem that dooms it. It may still be preferable to having nothing that works as release nears.
But a good example of where Agile just do
Only until I was told the secret (Score:2)
> I wager that on every single waterfall project you have worked on, there have been numerous change requests after the project was supposed to be "done." If it was a big project, I wager there were many change requests. In other words, the original requirements turned out to be fiction
That was true until someone told me the secret to finding out what the REAL requirements are. Once someone told me the secret, I learned the requirements ahead of time and took notes of what they were.
If you want to know w
Re: Agile is good for some teams & projects, h (Score:2)
Meanwhile, those of us who have more than a year of experience know that "waterfall" and "agile" are not the only process choices in the universe, we know how to plan for unknowns, and -- unlike agile -- we actually deliver reasonably finished products.
Trying to fit everything into single sprints is a recipe for code bugs and architectural rework. Making a toy version a higher priority than an appropriate amount of analysis and high-level design is a recipe for design errors and technical debt.
Re: (Score:2)
Ever tried Agile development of a software library or of infrastructural systems? Stuff that needs to be thought out before publishing? Where experience counts? Where you don't have a team of 10 people dedicated to sprints of two weeks? Where produced software actually has to be maintained? In short, where you have a small shop that needs to make a difference.
Agile is good to let badly planned projects die soon. Perhaps good enough to develop applications. Not so good if you have a team of experienced w
Re: (Score:2)
Ever tried Agile development of a software library or of infrastructural systems? Stuff that needs to be thought out before publishing? Where experience counts? Where you don't have a team of 10 people dedicated to sprints of two weeks? Where produced software actually has to be maintained? In short, where you have a small shop that needs to make a difference.
Yes I have, SCRUM was the process used, and it all worked vastly better than the three failed projects before it (in our extreme waterfall shop). There is nothing magical about SCRUM, or any other process, it's mostly about letting good people do good work. The thing that SCRUM et al, gives you is a tight feedback loop, and that is a very useful thing if you have it all going nicely. I've worked in all kinds of setups, from super heavy process (which I just can't stand, who wants to sit around for 6 months
Re: (Score:2)
That's actually pretty impressive. Good that it works out that well for you!
We invariably struggle with resources; We never get enough of them assigned to our projects. We simply have to make do with what we have. Failing to meet a client's target is never an option, so we need our systems to be easy to configure and we need a methodology that works with people that commit themselves.
Smaller projects typically have emphasis on configuration, testing and release management. Relatively little activity fro
Re: (Score:2)
Ever tried Agile development of a software library or of infrastructural systems? Stuff that needs to be thought out before publishing? Where experience counts? Where you don't have a team of 10 people dedicated to sprints of two weeks? Where produced software actually has to be maintained? In short, where you have a small shop that needs to make a difference.
Yes on all counts. At the same time.
I ran the dev team, already had experience of very early agile predecessors (DSDM), I was told to "do" agile with my team and went into it as a confirmed sceptic trying hard to keep an open mind, and f*** me it worked. Well. Really well. Several people (inc me) thought we couldn't do product development agile, couldn't do support and maintenance agile, couldn't support pre-sales agile, well we did, and it worked better than anything else we did in a whole lot of ways.
Re: Counterpoint (Score:2)
Ironically, saying people matter more than process is pretty much what the Agile manifesto says.
Re: Counterpoint (Score:2)
Ironically, the Communist Manifesto also says it values the working class people over the elites. In both cases, the hypocritical hyperbole fails in practice.
Re: Agile (Score:2)
It's a problem with agile and its proponents, who claim that agile is this wonderful process, but you need an awesome team with good management to make it work. If you have an awesome team with good management, your process needs are usually only defined by the total size of the team.
Not just development (Score:3)
Re: (Score:2)
Yup. Functional Decomposition is the silver bullet. No wait, it's Data Flow Diagrams. No wait, it's Rapid Application Development. No wait, it's Object Oriented Analysis/Object Oriented Design. No wait, it's Waterfall. No wait, it's Superprogrammer/Team Programming. No wait, it's Agile.
In the end a small group of good programmers will make a project succeed. Anything else will make it fail; it all boils down to whether the tech leads are competent or were promoted because they were someone's pets.
Management by magazine (Score:2)
I agree, this isn't an IT-specific issue. PHBs frequently make executive decisions base on what is promoted in trade magazines, which is a bummer for the workers who have to follow policy influenced by a marketing major.
Avoid the silver bullet that is Sencha ExtJS (Score:5, Insightful)
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.
There are no magic solutions (Score:5, Insightful)
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.
All this has happened before, and it will (etc) (Score:3)
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
This is the good old "Rapid Application Development" myth that has been doing the rounds since before many of today's trendy agile NoSQL programmers and the PHBs who encourage them were born. Even with things like Microsoft Foundation Classes and Borland's OWL that were used to create substantial apps, the initial drag-n-drool honeymoon didn't last very long. Then when Multimedia came along there were more "authoring systems" than applications created using authoring systems, and they were all great until y
Well, if it's got any javascript in it (Score:2)
Or is it SOA? Or Java? Or Windows?
If all you've got is a buzzword, you ain't got a business.
Yep. Quite recently. (Score:2)
Yep. Quite recently.
https://github.com/cloudtools/... [github.com]
Been there, done that. (Score:5, Interesting)
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 ...
Re: (Score:2)
I swear you sit in the same pod as I do...
Microservices are not hype. (Score:2)
Look at their example:
Example 3: Microservices
Step 1: Big monolith application scales hard. There is a point when we can break them down in
I used to work for an "Idea Man" and it sucked (Score:2)
I used to work for a (bigger than small but smaller than medium) family owned business doing web development.
The CEO and President were brothers, they were the sons of the owner.
One of the two was the idea man. He'd see something on a competitor's website or he'd read about it somewhere and call a meeting to find out what would be needed for us to do it too. We'd discus it, start developing a plan and get to it and three days later, there'd be another newer, shinier thing that he wanted us to work on. It wa
Re: (Score:2)
http://dilbert.com/strip/2016-... [dilbert.com]
NoSQL all the way down (Score:3)
Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases. But that's a solid, proven and ultimately boring technology. Where's the fun in that?
It's not just PHB driving the madness. Plenty of it comes from resume-driven development.
Re: NoSQL all the way down (Score:2)
This.
Re: (Score:2)
Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases
Hey, but PostgreSQL is buzzword compliant with the new hipness... you want a JSON-based document store?
CREATE TABLE docstore (
docid SERIAL PRIMARY KEY,
userid INTEGER REFERENCES users,
document JSON
);
OK, don't code-review that off-the-cuff doodle too seriously, but implementing NoSQL features in a decent RDBMS is easy, implementing RDBMS features in NoSQL is hard...
Ten easy steps to HDD (Score:3)
Here are ten easy steps that you can take to implement Hype-Driven Development for your project.
1. First, choose a new tool. Find somewhere that the tool is being used by a company everyone has heard of. Don't be too concerned about what they're using it for, or whether it relates to your work in any way.
2. When you start using the tool, don't mention it to anyone until you've already decided to base your finished product on it.
3. Don't bother finding out if the tools you have can already do the job you're doing now.
4. Expensive tools are automatically better than cheap tools. This makes it easy to measure fitness-for-purpose.
5. Even if you only use the tool to simplify very mildly half a line of code that's only used once, incorporating a new tool is still worth it.
6. Compare the tool by re-implementing some of your existing tasks. Only test the simplest and most trivial scenarios: if it works in a simple case, it's bound to work just as easily in a complex case.
7. Any inconsistencies with existing standards can be readily overcome by creating a new standard that the new tool fits exactly. Try not to be disheartened by the idea that you've previously been doing everything wrong for years.
8. Have some like-minded suckers re-implement everything even vaguely related to the new tool from the ground up. The more suddenly you can implement this, the more of an impact it will have - and impact is always cool.
9. If the re-implemented product turns out to be awful, or if it doesn't do what users want or need it to do, you'll be committed to the new tool by then, so it won't matter. Tell anyone who is critical of the product that it's too late to change it and that they should have raised their concerns earlier - especially if they did.
10. Stride confidently into your next performance review, knowing that even though you wasted a lot of time and resources to build a product that does slightly less than it used to, you've certainly achieved a lot.
Re: (Score:2)
(Score: 5, Sickening)
It depends (Score:2)
Re: It depends (Score:2)
Ha ha that was the first thing I thought when I read the article.
Two issues: methodologies and technology (Score:2)
There are two issues here, that need to be separated: Hype about development methodologies and hype about technologies.
If you have a good team, it doesn't matter what development methodology you use. It doesn't matter whether you have a scrum meeting every morning, or if you coordinate on a napkin over lunch - it's the team quality that matters. The rest is just formality, and provides a useful framework.
Technologies are more critical. Taking No SQL as an example: there are some very limited use cases where
No! (Score:2)
^Question in the title ?
The answer is No.
Re: (Score:2)
I'm not a developer, you insensitive clod!
Re: (Score:2)
Yes ! There's cloudy and rainy weather ahead !
As a rule of thumb, wait until a new idea (Score:5, Interesting)
...has proven itself for five years. The hard part is convincing executives of the five year rule. Often the benefits only appear in narrow niches or under specific conditions, but it takes a while for the industry to learn when and where.
Also, a lot "fads" are not directly technology fads, but rather obsessions. About 2 years ago our CIO became obsessed with SEO - Search Engine Optimization (Google hits, more or less), and so all kinds of silly games were played with our Internet content and CMS's, including mass repetition.
After a while people realized there was too much content to manage and clean up. That CIO moved on and the new CIO is a minimalist. Big change. SEO did nothing but make a mess.
We were suspicious of it all, but there was nothing we could do at the time but go with the flow. At least bullshit = jobs.
Re: (Score:2)
>> bullshit = jobs.
more precisely :
bullshit -> bullshit jobs.
Re: (Score:2)
If someone's feeding the bulls, somebody has to clean up the mess.
DHH article (Score:2)
That article from David Heinemeier Hansson wasn't that bad, actually. The title was truncated in the summary to make it more trollish.
He just said that he doesn't seek 100% unit tests coverage any more, and uses a mixture of unit and system tests.
It works fine in my experience.
It is a long list (Score:2)
Every new technology raises hopes, PHBs make plans, and then technical people are left into the mud, and have to help themselves.
Strangely, this did not happen when we coded in FORTRAN IV, but for sure it wasn't the language that was up to expectations, we just had few PHBs, all of them had a *sound* technical background, and there was no internet trumpeting every minute a new technology that solves everything real now, soon.
Java EE 6 (Score:2)
I tried to use Java EE 6. When it was new. Using CDI and JSF2 and JPA2.
So. Buggy.
It was (is?) a pile of half-broken components that talked to each other over mostly-broken interfaces. Work around a bug, hit another bug. Work around that, hit a design oversight. All those portable APIs you're supposed to implement stuff against only actually work if you only use one implementation, if you try to actually run on both Glassfish and JBoss AS 7 for example, you're going to suffer unless your app is a toy or you
Hypsters (Score:2)
That is why we old-timers call them hypsters
Silver Bullets (Score:2)
I was in a shop that loved silver bullets. The fact that none of them worked should have clued management into the fact that silver bullets don't work. But they tried kept adding different things to their development environment such as new tools and methodologies such as Agile. And everything had to be Java. Doesn't matter that the existing application was working fine, and had been for years, it was going to get converted. They were even going to convert formmail.pl (it's been a while but I think that
Team? No. Me? Yes, but I have also avoided hype. (Score:2)
Good teams usually mitigate the hype effect, because they are diverse in setup and bring along multiple perspectives.
I myself have fallen for hype a few times, as I guess we all have. I remember using Cake 1.2 beta, because "New Features!". ... Bad idea. Blew up in our face twice a week and delayed the project way too much. even discouraged from the core team. Typo3 was more of a local hype of German-speaking countries, but following that a little bit was more of a neccesity than hype.
I clearly remember con
yes (Score:2)
The root of all evil is careerism. (Score:3)
Too often developers choose to use a technology because it will look good on their resumes, not because it serves the interests of the system's users or the people paying for it. It's what economists call "agency costs".
Every time a new golden hammer comes up, developers rush to use it before they get left behind. And you can see the corrupted focus right in the code. I remember when Model-View-Controller was the buzzword du jour, and people without any sense of irony whatsoever would bake MVC framework dependencies into practically every single file. Ugh.
But here's the rub: part of taking care of user and customer needs is considering the impact of future brainshare. Sure, COBOL may be just perfect for this app (OK, probably not), but should you really saddle them with having to find someone with COBOL expertise? It's possible to be too puritanical about avoiding technology fads.
So part of your job as a developer is to track the emergence of new golden hammers, to study good and bad examples of their use, and to truly understand each of them as much as possible. Where possible you should try the latest thing; if you're a team manager assign slack personnel to do spikes that evaluate it (this is a great perk to hand out). It's part of your job to stay on top of where things are going, without committing customers to something that might not meet their needs.
perl programmers are (mostly) immune to hype (Score:3)
I'm a perl programmer, almost by definition I don't get hired by places that insist on chasing the new shiney.
The tendency of programmers in general to be as trendy as a bunch of teenagers has not been lost on me, however (like I said, I'm a perl programmer).
Somewhat more disturbing is a tendency of perl-culture in general to be a bit faddish... one year it's inside-out objects, the next year it's the Moose family, one year Module::Build is the greatest, the next Extutils::Makemaker has made a comeback and no one wants to hear about anything else, one year ORM are the bees-knees, the next it's the NoSQL fad, then it suddenly dawns on people you don't really want to try to do schemaless data...
Re: He sounds like an idiot (Score:5, Insightful)
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.
Re: He sounds like an idiot (Score:2)
Precisely the OP's point.
That's a typical trait of a junior developer, or an experienced developer who has worked solo for most of they're career.
Re: He sounds like an idiot (Score:5, Insightful)
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.
Re: (Score:2)
Well said.
Re: He sounds like an idiot (Score:4, Insightful)
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.
Re: He sounds like an idiot (Score:4, Insightful)
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.
Re: (Score:3)
FWIW I often compile with Mono because I like my tools to be cross-platform. I find that compatibility between .NET and Mono is excellent anyway.
Re: (Score:3)
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.
The complaints I've heard didn't generally sound so irrational. I thought the consensus was "It seems like a good language, but still most useful in building things for Windows. Maybe that will change as the cross-platform stuff improves, but for now, I'll stick with [whatever language they're using]." Admittedly, I'm not a real programmer and only get a sense for what programmers think from this site.
Re: (Score:3)
Re: (Score:3)
That's why planning is important and choosing the technique before taking a major step is the way to get that experience. Solving toy pr
Re: (Score:3)
Yes it's as good as you would Expect and is the proper way to do an involved script GUI interface.
However sometimes a couple of lines of bash using zenity does the job and is pretty obvious to anyone who has to alter it later.
Re: He sounds like an idiot (Score:2)
Reaf TFA. These are exactly his points. So you are the idiot.
Re: (Score:3)
You ask on stackoverflow, of course. *eyeroll*
Re: (Score:2)
My development team isn't that particular flavor of retarded.
and your team is not interest in profit.
Re: (Score:2)
Step 1. Make sure your have the proper "apple favicons" and metas. Use http://realfavicongenerator.ne... [realfavicongenerator.net] to complete 99% of the job.
Step 2. Show the employees how to "bookmark" a website.
Step 3. Profit!