The pitfalls of GDD.

Over the years, I have sampled approaches to software development ranging from RAD, XP, Waterfall, Agile, Scrum, SOA, TDD, and have recently started looking more seriously at the BDD/DDD(D) camps.   However, throughout my forays into this potpourri of acronyms and metaphors for programming, I continue to find myself falling back on the crutch of GDD – the least Agile and productive approach of all.

Yes, I’m referring to none other than the ubiquitous Google-Driven Development (GDD). 

Its like when I first realized how dependent upon Intellisense I had become, except now I find that GDD is far worse since it is simultaneously more subtle, insidious, and disruptive.    At least Intellisense tries (yet arguably fails) to help you get things done faster, but GDD despite its popularity and benign appearance is truly the greatest time-sucking vortex in the universe. 

GDD dulls the developer’s mind, lulls us into a complacency about trying to solve problems ourselves – since by simply Googling, you can let others provide an answer for you.  GDD is like dark-matter obscuring developers from grokking quality software engineering.  It is the elusive Higgs-Boson particle of development that is driving us toward anti-productivity and mediocrity.  It is the reason why aspiring developers’ growth often stalls mid-career, becomes stunted and eventually causes them to revert to (MS-style) demoware quality development rather than maturing into true software engineers, craftsmen, and thought-leaders of the industry.  GDD is more subtle than the common-cold and a greater pandemic than H1N1, and it must be eradicated. [1]

Inevitably if we continue to abuse GDD, we may one day be faced with a future similar to that depicted in the fictional (yet highly plausible) movie Idiocracy where our development communities are filled with below-average developers and hacks who are ruled by a few barely-average people and their well SEO implemented code repositories.

Diagnosis

I implore you to perform this self-diagnostic test today to see if you too have acquired the GDD addiction:

Ban yourself from Google (and/or Bing) for 1 day…If you find that you struggle to produce code without searching for 3rd party libraries & open-source, notice a sense anxiety at being unable to find blog code samples, feel concerned that you cannot validate your ideas against posts in forums and sample apps, or cannot make coding progress without seeking out online API’s and reference sheets, then you too may suffer from Google Driven Development. [2]

Remedy

GDD is difficult to completely eradicate from our lives, however here is a proven 7-step  approach that helps to reduce its harmful affects;

  1. Blank Browser - Change your browser start-page to about:blank (or equivalent) rather than a search page.
  2. Cleansing Period - Perform a 1 week cleansing period of total search abstinence.
  3. Moderation - Afterward, slowly reintroduce Google and other search tools with extreme moderation.
  4. Reward Abstinence - Reward yourself each time you successfully complete a task without search that normally you would have. (note: don't use GDD as a reward for GDD abstinence)
  5. Cheat Hour - Schedule one timed GDD Cheat Hour each week where you allow yourself to indulge in unadulterated hard-core GDD.  (Note: make sure the 1 hour isn't exceeded)
  6. GDD Diary - Keep a log of how much time you use search tools for development. (Tools like RescueTime.com may help)
  7. GDD Monitoring - After 21 days of intense anti-GDD focus & moderation, open up your calendar and schedule 1-2 days of GDD abstinence each month to measure your progress.   If abstinence of GDD still causes excessive anxiety, repeat these 7-steps.

Note: beware that its common to see GDD sufferers seek-out alternatives, or shift habits towards Twitter, StackOverflow, and other social networking sites.  These are just variants on GDD, each with its own set of problems, thus should be avoided. [3]

Good luck!

 

[1] Okay, I’m not really saying never reuse code, but hey, try writing some stuff yourself first and at least you will better understand the problem rather than taking other developers’ word on how to solve it.

[2] There is obviously some truth in this post, but I really hope you don’t think that I’m totally serious and off my rocker with all this stuff.  Its just a fun way of pointing out something we all know already, which is that we tend to go down rabbit-holes when we google anything, and waste more time googling and digging than it might have taken to write it ourselves in the first place.

[3] This is also a belated partial-rebuttal of Phil Haack’s 2007 post “Increase Productivity With Search Driven Development” in which he argues the value of Search for code/solution discovery.  I don't even mention the risks to Intellectual Property and job security if you are a commercial product developer…

7 Comments

  • My two cents on this topic.
    I google every class I use and don't know. If MSDN is in the search results. I'll read the complete class. members and code samples. Unfortunately the code samples or clear description lacks a lot of times on MSDN. So than I look for a few samples on how other people use these classes. Even in books on my desk! Once I have a firm grip on what the class is intended for and how it can be used, I create my own code, using all combined knowledge.

    Truly don't know what's wrong with trying to read a manual before using the apparatus. I consider it a form of "Think/research first, code later".

    Cheers,
    Wes

  • Great idea, I have 3+years of experience in .net but I could not even think to write code to complete a page with out using google.

  • @webbes -

    References have their uses, and so do tutorials, but they shouldn't become a substitute for independent thinking and trying to solve problems yourself.

    You would be shocked at how many candidates I have interviewed who struggled to write a C# switch block or enums, or who couldn't implement ASP.NET pages without looking up page lifecycle events and databinding syntax.

    My concern is that many developers today including myself aren't disciplined enough to sit down and learn a new tool, library, or framework before using it. Instead they use GDD as a just-in-time research tool and they query just enough for the immediate problem, then code a bit, then google some more, then code some more, etc. All the while, using a lot of copy/paste re-use of other people's code that may never have even been vetted against a production environment.

    This eventually gets to the point that you don't trust yourself to just try coding something and are afraid to make mistakes, or maybe even invent your own code-snippet rather than borrowing someone else's.

    Coding is fun. Why let someone else have all the fun while you do simple copy/paste grunt-work? This is where I love the idea of using daily/weekly Katas & other coding exercises by which develop your confidence and trust in your own abilities.

  • @Mike S -

    I agree completely. The big problem with GDD isnt that people are learning things via the web (and search), its the fact they are doing it WHILE they code rather than BEFORE they code.

    My main focus in this article is the productivity killer and the failure to let your domain drive the implementation.

    Its the code, search, code, search, code, search, mentality that kills productivity and often times causes developers to under-think their code by just copy/pasting a blog-sample and calling it done.

    From my experience this is a disaster because you aren't thinking about your problem domain and adjusting the code to fit your constraints and needs. Instead you are taking the word of another developer on what you need, yet they can't possibly have any clue how you are using it.

    This can be solved by refactoring, but your better option is to stop, do research, learn the framework/library/whatever and then write your own code, using theirs as a guide, but not a complete drop-in for your work unless it truly fits.

    Over time of working with a framework, you should develop a competence and confidence with your skills and rarely have to google about it. Instead you are focusing upon the business problem at hand.

  • Lance,

    If you're like me, then thirty years ago I could remember off the top of my head every call into the Unix API and most of the library functions as well. But when it comes to .NET, I can only remember the details of the classes I use every day. So I really don't know if this is a reflection on programmers getting lazy, or interfaces getting too complex. Considering that Windows API itself often had two or more entry points that did the same job, but coded by separate groups, I think perhaps the environment has just become too big for anyone other than a super-hero to handle :)

    Joel

  • @Joel_Mussman -

    You bring up a good point.  In the back of my mind I have been thinking about the question of "why" we feel the need to google.  I think this article addresses the addiction factor to a degree, and how we can become dependent, but it doesnt address the underlying cause of this need for searching.

    The biggest problem we have today is discoverability for code samples, libraries, and frameworks.  MSDN has become simply horrible, so people rely more on 3rd party references, and thus the searching & rabbit-hole diving begins.

    Ruby has solved this somewhat with RubyForge.org & Gems, and we are starting to see this adopted with .NET projects re-using gems for our libraries and those creating .NET package management tools like Horn Project and the ruby-driven Nu tool.

    I see Microsoft's Web Platform Installer as an attempt too, but it falls short on getting you up to speed quickly.  Granted, even Ruby Gems don't do much more to solve that problem other than distributing help docs with the gems.

    There is definitely an opportunity here if someone can find the right solution to close the gap from problem-to-discovery-to-solution.

  • "Its just a fun way of pointing out something we all know already, which is that we tend to go down rabbit-holes when we google anything, and waste more time googling and digging than it might have taken to write it ourselves in the first place."

    Which, ironically, happens to be how I found this blog while looking for a code solution.

Comments have been disabled for this content.