Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming IT

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?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Has Your Team Ever Succumbed To Hype Driven Development?

Comments Filter:
  • about Black Belt training?

    • by Greyfox ( 87712 )
      I did a contract with Sun, just before they went under. The employees were quick to tell stories about how they used to hire magicians to come and entertain on the campus. There was this one guy, sat a cube over from me. Near as I could tell, his job was to sit on the phone all day boasting about whatever next conference he was going to and how he was a certified black belt. That was the only time I'd ever heard anyone talking about it. At Sun. Just before they went under.
    • I can assure you TDD is not dead but don't expect to master it if you still have difficulty grasping the concept of Unit Tests. Learn to walk then learn to run
    • I just looked around my team I didn't realize apathy was a new trend
  • Infinite web pages (Score:5, Insightful)

    by qzzpjs ( 1224510 ) on Monday November 28, 2016 @12:58AM (#53375047)

    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.

    • by Tablizer ( 95088 ) on Monday November 28, 2016 @04:09AM (#53375601) Journal

      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.

    • by dave420 ( 699308 )

      None of that is mutually exclusive with infinite scrolling websites.

    • by houghi ( 78078 )

      I hate that stuff, especially if the sneaky bastards have the info and legal part at the end of the page.
      To me that should be illegal.

      • 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.

    • Also, on infinite web pages it's scroll scroll scroll and YOINK, you have lost your place.
      • by Solandri ( 704621 ) on Monday November 28, 2016 @08:50AM (#53376421)
        More precisely, it's scroll, scroll, scroll. Ctrl-click to open a link in a new tab. Except you didn't hold down ctrl enough and the link opened up in the current tab. You hit back on your browser, and now you have to start scrolling from the top all over again. Whoever came up with the idea for infinite scroll web pages should be forced to go home and start his trip all over again every time his GPS tells him to make a turn and he misses it.
  • 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)

    by Anonymous Coward on Monday November 28, 2016 @01:01AM (#53375069)

    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.

    • "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.

      • That's why in my previous job I always tripled my estimates and made sure that my colleagues make so too.

    • by dbIII ( 701233 )

      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.

      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

    • Exactly, and that's why the author of the article advocates testing and research: understand the nature of the beast before attempting to tame it. This is classic innovation management. What I missed from his article is another important aspect of innovation: knowing when to quit (and planning for an exit). Define success criteria, have regular evaluations, keep room for changing tack when your insight changes, and stop when your goals aren't being met. And of course to define those success criteria, yo
  • Agile (Score:4, Informative)

    by zm ( 257549 ) on Monday November 28, 2016 @01:06AM (#53375085) Homepage
    Although, it was due to a sustained level of hype, rather than an epiphany by the powers that be.
    • 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)

        by WaffleMonster ( 969671 ) on Monday November 28, 2016 @01:52AM (#53375223)

        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".

        • 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)

            by Anonymous Coward on Monday November 28, 2016 @02:42AM (#53375361)

            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.

            • by ranton ( 36917 )

              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)

            by umghhh ( 965931 )
            market has hardly anything to say about it. The fact is that projects being difficult to compare are also difficult to draw conclusions upon. I actually have made a comparison of two projects running on two different platforms and using two different (*) paradigms - my corp just bought another corp where exact same thing has been done already but as said on other platform. The one had 300% higher cost than the other. The thing is - when I proposed to have a look at the reasons and do root cause analysis I w
        • Re:Agile (Score:5, Funny)

          by Chris Katko ( 2923353 ) on Monday November 28, 2016 @04:11AM (#53375611)

          The No True Agile fallacy.

        • by Tablizer ( 95088 )

          This is all proponents of Agile ever say..."Your doing it wrong".

          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.

        • Agile is simply about detecting potential project failures as early as possible and responding to requirement changes as they change. Rather than doing a 2 year development cycle only to discover that not only has the clients needs changed and the software now doesn't do what they need anymore but the project wont work anyway because of X.

          I mean why lose two years work when a months or better still two weeks would have done just as well

      • by raymorris ( 2726007 ) on Monday November 28, 2016 @01:54AM (#53375233) Journal

        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.

        • by Kjella ( 173770 ) on Monday November 28, 2016 @03:05AM (#53375459) Homepage

          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.

        • 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

          • 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.

      • 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

        • 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

          • 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

        • 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.

  • by hcs_$reboot ( 1536101 ) on Monday November 28, 2016 @01:23AM (#53375137)
    It happens all the time. Everywhere. As soon as a trend arises on the horizon many companies jump on it to get their share of the cake. And it's even not unprofitable.
    • by tomhath ( 637240 )

      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.

  • 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.

  • by EmperorOfCanada ( 1332175 ) on Monday November 28, 2016 @01:33AM (#53375171)
    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.
    • by chipschap ( 1444407 ) on Monday November 28, 2016 @02:51AM (#53375401)

      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.

    • 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

  • it must be good.

    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.

    https://github.com/cloudtools/... [github.com]

  • by Zarjazz ( 36278 ) on Monday November 28, 2016 @01:59AM (#53375249)

    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 ...

    • by Hylandr ( 813770 )

      I swear you sit in the same pod as I do...

    • Microservices are not hype. Anything that lets you scale your code without having to rethink how you write code and while reducing cost is pretty amazing. If anything, I'd say microservices are underutilized these days, because it is often easier to start a new holistic system and architecture it for microservices than to convert aging systems to use a new model.

      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 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

  • by anchovy_chekov ( 1935296 ) on Monday November 28, 2016 @03:11AM (#53375479)
    Once upon a time I worked on an app that had 4 databases - MySQL, Redis, Neo4J and Influx. Each of these were to solve a specific problem (searching, time-series data, etc) even though the scale of the application (a handful of users per day) never warranted any kind of "big data" solution. And the fundamental problem remained - many of the developers didn't know how to write decent SQL.

    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.
    • 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...

  • by roesti ( 531884 ) on Monday November 28, 2016 @03:19AM (#53375499)

    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.

  • Does "whatever our Microsoft rep wants to sell us" count as "the latest thing"? If so, yeah, been there.
  • 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

  • by stooo ( 2202012 )

    ^Question in the title ?

    The answer is No.

  • by Tablizer ( 95088 ) on Monday November 28, 2016 @03:49AM (#53375549) Journal

    ...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.

  • 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.

  • Windows, Linux, C++, python, agile, scrum, ....
    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.
  • 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

  • That is why we old-timers call them hypsters

  • 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

  • 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

  • I work for a company that makes apps. We rushed to release an Apple Watch extension as quickly as possible after the Watch's release, for the sole reason that we wanted to be able to issue press releases about how we support Apple Watch and are super-innovative while our competitors are not. Nobody thought it would drive sales from a feature perspective, except insofar as it could create the perception that we're "cutting edge" and "innovative". Never mind the fact that our Watch implementation was extre
  • by hey! ( 33014 ) on Monday November 28, 2016 @12:47PM (#53377833) Homepage Journal

    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.

  • 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...

Forty two.

Working...