Fearless Bit

memcached has been a topic of discussion for me recently, so “How I learned to say ‘No’ to SQL, NoSQL” piqued my interested.  FTA

I imagine most developers are familiar with memcached and products such as Oracle Coherence when it comes to caching and data grids. There is also Berkely DB, a persistent key/value store. However, Dynamo is both distributed and persistent.

I got two good friends of mine sucked into the idea of running an SSDs.  They chose to use the OCZ Vertex 250 GB.  This was back in April.  This is when their version of Hell started.

I’d posted about these drives before and these looked like a great alternative to the super-expensive Intel drives.  Well, the short version is, stick to the Intel drives.  These drives self-destructed repeatedly in their Macbook Pro’s.  The data would simply get corrupted.  Months of back-n-forth with OCZ proved fruitless.  Their RMA process was the worst I’ve ever seen, taking over a month to move a drive from customer premises to vendor or vice-versa.  Their tech support was slow, clueless, and never bothered trying to ask how to reproduce the problem.  A new set of drives were shipped, and they exploded just the same.  OCZ continued to claim they can’t reproduce the problem, but never took up the offer on how to reliably reproduce the problem using the customer’s input.  At this point, $1600 tied up, my friends are understandably irritated, and asking for a different solution — ship a different model or refund the money.  OCZ of course first opted for a different model.  Well, after another month of waiting for turnaround (they have my friend’s drives during this time) and constant “where is my drive? what’s the status?”, OCZ finally comes back and says “sorry, the model we were going to ship you is discontinued.”  So, they shipped a third set of Vertex drives — tested, formatted, etc.  My friend plugs it in, and after writing the directory entry for “/” during the OSX install, the drive puked.  It doesn’t even show up as formatted anymore.  Naturally my friend is furious, and wants a refund.  He pulls the drive out, and comes to find that the “warranty void” sticker is pierced and the screws were clearly “used” — strange to say the least.  My friend learns the engineers were manually wrangling with the drive for some reason prior to shipping it — presumably to make sure the drive was OK.   At this point, we’re into September —5 months into the ordeal.   My friends managed to convince OCZ to issue a refund.  It will probably be another 2 months before they see the check.

Maybe their other products work fine.  Maybe the Vertex works fine on a Windows PC.  Who knows.  But I can tell you I’ll never buy OCZ (obviously neither will they) after that disgusting excuse for customer support.

I’m sticking with Intel.  My X25-e continues to perform flawlessly (I’ve had it since ~March).

I’ve been slacking on this site because I’ve been ridiculously busy supporting what’s going to turn into something huge.  The Intuit Partner Platform is unleashing the ability to create RIA’s by leveraging Flex, an Intuit-developed framework, Intuit services, and the enormous Intuit customer ecosystem (think QuickBooks).  The resulting apps live on the AppCenter.  Check out the coverage.

Now, back to our regularly-scheduled programing …

• 45 Free Online Computer Science Courses
• How to TDD a database application
  Think you can’t do it?  You should probably read this …
• 9 Ways Developers Fail to Accommodate Business
  A great developer does much more than code … I personally struggle with Justification Fail and Knowledge Transfer Fail.
• The 80/20 rule – the Pareto principle
  I agree that there’s a “sweet spot” and we often forget about that, lose focus, and do the wrong thing.
• Just another Software Engineer: Testing software quality – open your mind
  The author’s first eye-opener resonates with me; it amazes me when the most basic bugs are discovered by QA — presumably because the developer step into the shoes of a tester prior to committing the code.
• Test Infecting Your Team
  I still hear the cries of “I don’t have time” or “it’s not worth it.”  I always lobby back.  Hey, there’s plenty of articles like this out there — plenty of people who believe and practice this stuff.  They’re not all wrong.
• An Easy 5 Step Process for Test Driven Development
  I’ve heard developers ask “how can you write tests without the code first?!”  Here’s a demo on how …
• Agile Testing vs. Traditional Testing
  I almost gave up on the video in its early parts — but don’t.  If you’re struggling with Agile practices, the benefits they provide, what QA deals with, etc. then watch this.

“Ensemble Tofino for Visual Studio is a plugin that enables .NET developers to create Flex front ends for their applications in the same IDE that they normally use.”

http://www.ensemble.com/products/tofino.shtml

While reading 10 Things I Hate About Software Development, I came across a list of nine things that kill teamwork that TomDeMarco and Tim Lister in their book Peopleware.  I followed the link through to find out what that list was and found myself nodding in vehement agreement with them and the examples that the author of the article listed.

How much do those nine killers ring true with you?

Ran across this article just now and wanted to link to it cuz the concept is really fascinating to me!

http://www.jroller.com/nivanov/entry/cloud_based_thread_pool

What’s more important for a SaaS business: making money on every user or having so many users that you can then create features that are only useful when you have these kinds of numbers?

This article on GigaOM really caught my attention because it’s dear to the hearts of the team I work with.  Creating feature after feature may not be what’s needed to grow — but rather create one or two compelling reasons to be on the platform, and then use that network effect to create additional features that benefit large numbers of users.

What makes the company that provides an online service successful?  At a mid-level view, the list is large, so I’ll focus on the items related to this posting:

1. Working smarter, not harder
2. Try, learn, and improve
3. Solve problems that matter to it’s customers, employees, and shareholders

These often mean different things to leadership than they do to an engineer like me.  We share the same high-level goals, but our lenses are naturally different.  Managed correctly, this is a good thing.  However, it’s human nature for these differences to create problems.

When the organization chooses a direction that I know from experience will violate one of the 3 items above, I find myself in a quandary.  Some people tell me to “support the business.”  Others tell me “it’s just a job.”  Personally, I take great pride in my work and feel very personally dissatisfied knowingly choosing (or being forced to choose) the wrong path.  I also want to do what I can to help the business not only succeed, but thrive.  I don’t like to lead a mediocre career.  So what should I do in these situations?

The answer might seem simple: speak up!  You can safely assume that I do.  So what’s wrong?  Where is the message getting lost?  How does an admin/engineer provide cost/benefit or ROI analysis on something as vague as architecture (especially without the resources to test its limits)?

There’s too much to cover in one posting, so here’s an outline of what I’m thinking about for my next posts:

• Trust your senior engineers in their domains of expertise; allow them to make mistakes (see #2)
• Allocate sufficient resources towards becoming and staying proactive, not reactive (#1)
• Complexity kills; follow the KISS principle (#1)
• Don’t re-invent the wheel (#2, #3)
• Enforce processes via consequences (#1, #2, #3)
• Balancing long- and short-term (#1, #2, #3)
• Personal and organizational effectiveness topics (e.g. Stephen Covey’s publications)

This is meant to be a series of interactive posts — which is part of the reason for breaking it up into several digestible chunks.  I hope to absorb and integrate the feedback that I get.  Please share and comment!  Thank you!

Being that I own a really expensive high-performance SSD that’s only 64 GB, I torture myself by watching this technology space and if Corsair’s numbers for this drive hold up (and the drive holds up), the OCZ Vertex may have a real contender.  Engadget’s coverage is here.

• Release It! Review in “Quotes”
  A review of the book Release It! — there are a fair number of people in the comments of this review indicating this book is a must-read.  While I don’t develop software, I’ll probably read it as topics like these speak out at me:
  • Data purging isn’t sexy but needs to be done
  • Temporary fixes are inevitably permanent.  We all know the various forms of “temporary is never temporary” yet we all still do it.  If I could slap someone every time I saw it happened, my hand would be raw
  • Design for capacity; sure, the architects do it but the developers generally don’t get it
  • The cost of (un)reliability
  • Don’t GUI-up an admin interface.  I wish I could have a revision-controlled set of configuration files for production …
  • Logging needs to be desgined for operations; if you log an error, it better be because you need my help as a System Admin!
• Seven Productivity Tips For People That Hate GTD
  GTD = Getting Things Done.  This is an interesting look at some ways to improve your ability to execute.  I took a look through the site because there are a number of related books and articles and, well, I’m all about reading up on how much I don’t know … 🙂
• Why McKinsey’s Cloud Report Missed the Mark
  On my April 19th post, I referred to a McKinsey study regarding the real cost of moving your business to the “cloud.”  Joe Weinman at GigaOM points out that this isn’t such a black-and-white issue.  Much like there’s a valid, proven business model for renting cars at 5 times what it costs to own, there are reasons why someone might want to use “the cloud” even if it’s actually more expensive because it’s more flexible (e.g. you can instantly fire up 1,000 servers — try doing that at your own datacenter) which can translate into cheaper overall
• The Big Agile Practices Survey Report (Part 1)
  Did you read Fearless Bytes IV?  If so, you’ll be happy to know that the results are in for The Big Agile Practices Survey!  It should not only get you thinking about whether it matches what you value, but if you’re a manager or leader, it may make sense to see whether aligning yourself to these results or carrying out the same survey internally makes sense