View Sidebar

ardent dev by derek hatchard

ardent dev is about topics relevant to the professional lives of software developers. Essays by Derek Hatchard and guests. Check out the archives.
The Contemplative Pause

The Contemplative Pause

I have come to truly appreciate a pause after someone has finished speaking. It (often) means that people are genuinely listening and then taking time to mentally compose a response. The pause is indicative of thoughtful listening. A meeting characterized by people talking over each other or a series of monologues has a lot of content but dubious value if others are busy preparing their own remarks instead of listening.

Of course the pause can also mean people simply aren’t engaged in the conversation. Laptops and smart phones in meetings lead to a culture of partial attention that is destructive to thoughtful discourse. People tune out the conversation then perk up when they hear their name or some other trigger word, asking the speaker to repeat what he/she just said. Then someone who wasn’t really listening jumps into the middle of the conversation, leading to dumb comments or dumb decisions. If I offered to significantly reduce the IQ of all the people on your project, you probably wouldn’t take me up on it. But we inflict the same consequence on ourselves voluntarily (see: Multitasking Is Making You Stupid).

My wife, who tends to be more extroverted than me, would say that many extroverts need to talk through their thinking process so my appreciation for the contemplative pause is biased because of my more introverted personality. Maybe. I’ll have to think about.

January 31, 20146 commentsRead More
Building Software is Like Buying a Puppy

Building Software is Like Buying a Puppy

Scott McNealy and Scott Hanselman have both said that open source software is free like a puppy, but a lot of open source software is free like a mature housebroken dog you get from a friendly neighbour. Building software, on the other hand, is like buying a puppy. A really young puppy that’s not housebroken. With its tail held on with tape and wire. And it probably started out as a dire wolf or a cat or a gerbil.

It’s exciting to buy a new puppy. You envision a blissful future with walks in the park and playing fetch at the lake. You aren’t thinking of the late night walks in the blistering cold or trips to the vet. We build software thinking of all the ecstatic users who will flock to our creation. Our euphoria causes us to minimize in our minds the pain of the support calls, the server maintenance, the bug fixes, the security patches, the Cyber Monday web site failures, and the never ending list of nice-to-have features that won’t make it into the first release.

When an enticing software project is staring at you with those big puppy dog eyes, try to remember the following points.

Puppies Need Attention

I can think of two software projects I worked on in my career that reached a stable feature set and remained in active daily use without intervention for months or years at a time. Most software needs some level of care and feeding whether it’s bug fixes or investigating run-time errors or replacing a failing hardware component or renewing a license. Anything nontrivial that you throw up on a server or give out to users is going to generate work for you in the future if people start using it.

More than a decade ago I took over a small software product. If I recall correctly, a license was $150 and an annual support contract was $80. I stopped selling licenses and support for that product 5 or 6 years ago yet 2011 was the first year I didn’t receive at least one request for help from someone.

Puppies Have Ongoing Costs

Software is never truly free of cost. Delivery of software costs something even if it’s trivial at low volume. If you host software as a service, you have server and bandwidth costs along with storage for backups, web site hosting, and domain name registration. Even some little open source utility you release on a whim requires some bandwidth for downloads. In some cases you can offload those costs to someone else (e.g., put projects on GitHub) but the costs still exist.

And remember that software requires attention. Unless you personally are doing all the work out of the goodness of your heart, someone is getting paid to pay attention to your little puppy.

Puppies Can Be Sickly

Somewhere right now someone is releasing software with bugs in it. “Known Issues” is a whitewash of a phrase that tries desperately to make it sound like the team behind a software release is really on top of things, but it is really an admission that a release is flawed or incomplete or imperfect by someone’s standard. Known issues lists are a well-established tradition in the ritual of releasing software and I’m OK with that as much as I cringe to ever see a Known Issues list.

The more problematic yet equally well-established tradition is releasing software rife with unknown issues. There are plenty of best practices for increasing your confidence in the quality of your software before releasing, but bugs still make it into software that was considered ready for prime time. People who take seemingly healthy pups home from the SPCA aren’t expecting emergency visits to the vet the next night. Or for the puppy to refuse to eat. Or for the puppy to violently attack the cat. But it happens sometimes. When you unleash your puppy unto the world, be prepared to deal with an emergency if one arises.

Puppies Can Invite Over Some Unsavoury Friends

I’ve always been a little weirded out by those little pet doors. A door that lets your pet come and go freely can just as easily let other animals come and go freely. Every piece of software you deploy is potentially a little door into your database, your network, or your file system.

Your software can be up and running for months or years and then one morning you get a frantic 5am phone call from your database administrator saying your database records are gone except for one row full of profanities.

Crap.

Before you roll out a piece of software, ask yourself what you will do if a critical security vulnerability is discovered. This is especially important if you are outsourcing development work as the original dev team members may not be readily available to address a critical issue quickly and an attack can happen anytime. You are never truly safe. It might be years before someone discovers you have a vulnerability or an operating system update might open your systems up to a zero-day exploit.

Puppies Can Grow Up To Be Big Dogs

Have you ever visited a relative with a little yappy lap dog that comes tearing down the hallway barking at you like you are evil incarnate come to enslave the household he so valiantly defends? No big deal, just a little dog. But if a 95 pound German Shepherd is running at you full tilt with a crazed look in his eye, that’s a different story. You’re going to pay close attention to his every move as your life flashes before your eyes.

When you are building software, you hopefully have a general sense of the scope of the project and the target audience. You should know within an order of magnitude how many users you will allow on the system and whether you expect the user base to stay relatively constant or grow significantly over time.

And then things change. Oprah recommends your wedding planning app. Your sales team signs its first large enterprise customer. Your DIY clothing design software is featured in a syndicated fashion column. Or user adoption grows 5 or 10 or 1000 times faster than projected because your software simply kicks butt.

Whatever the reason, if your software is successful, you will have to deal with it. And while that can be a great problem to have, dealing with fast growth and scalability can be very challenging. Suppose you started out with a little side project on a shared hosting server. Demand hits hard so you have to move to a dedicated server, then two, then three. Then demand spikes and you can’t get servers fast enough to keep up. Performance lags and key customers start calling to complain. Although you don’t have a firm SLA, big clients start asking for refunds and your project is suddenly in the red and tarnishing your reputation with your customers.

The Twitter “fail whale” is a perfect example of how painful scaling can be (http://en.wikipedia.org/wiki/Twitter#Outages).

Make sure you know what you’ll do if your little puppy grows into a 300 lb Mastiff.

Caveat Structor (Builder Beware)

The ongoing costs and commitments associated with creating and running software are frequently overlooked or underestimated by stakeholders. As software builders, we need to consider the long term implications of our decisions to build and release a piece of software. Failure to think about the costs, commitments, and risks in advance can leave you wishing you had never decided to adopt that puppy.

Photo credits: klearchos, chrisk4u



December 15, 20110 commentsRead More
Microsoft Vitriol

Microsoft Vitriol

For much of the last decade I have received varying amounts of grief from colleagues for being so invested in Microsoft development technologies. For a professional demographic that prides itself on a mastery of logic, developer attitudes toward Microsoft can be downright bizarre. They are regularly inconsistent and frequently irrational. Developers can be almost religiously pitted against Microsoft technologies with little grounding for their vitriol.

I have always tried to be pragmatic with technology. I have lived on DOS, Windows, a few flavours of UNIX, Linux, MacOS, and OS X. I have coded in C, C++, Java, VB3-6, VB.NET, C#, Perl, PHP, Ruby, Python, various SQL variants, JavaScript, and a few other languages. So I feel like I have a fairly balanced perspective from at least the last 15 years of mainstream OSes and languages (except for general purpose functional languages). Every platform and development stack has its share of warts. No platform and/or language is inherently nor universally superior to everything else. Certainly every mainstream platform has merit. Even PHP, I must begrudgingly admit, has a long list of positive qualities.

I will admit that at times I have jumped to the Microsoft stack for a project without giving serious thought to alternatives for the sake of expediency or practicality. If you have a Windows Server running IIS and SQL Server on hand already, it just makes more sense to build an ASP.NET app than a LAMP app. If you want to build a large natural language processing cluster, it probably makes more sense to use C++ or Java on Linux boxes. If you want to write a native iOS app, use Objective-C.

What repeatedly surprises me is how quickly developers will embrace an open source project with barely a thought to whether it’s been thoroughly tested, the license attached to it, or the future plans of the project founder/coordinator. But anything that comes from Microsoft is dismissed out of hand or viewed with a great degree of skepticism regardless of the substantial resources Microsoft has thrown into product planning, development, and testing.

The anti ____, pro ____, no ____, only ____ mentality has become exceedingly tiresome. Imagine how much more collaboration we would foster if we respected the preferences and choices of our colleagues instead of treating them like misinformed degenerates who don’t deserve our full professional respect. It is time we get down off our high horses, bandwagons, and soap boxes to interact with our peers in the trenches where good work is getting done with many different tools and approaches.

Microsoft Values

In response to this, my friend Dirk at IBM says his problem is primarily with the values represented by Microsoft as a software company and "behaviour that go[es] beyond the ‘they need to please their shareholders’ arguments people often use to defend corporate ethical lapses." And indeed he brought up some murky situations including Netscape, WordPerfect, the SCO trial, and the Microsoft JVM.

I do agree that Microsoft has had its share of corporate ethical lapses, although my original email to the Ardent Dev list was about developer vitriol toward the Microsoft technology stack rather than the behaviour of the corporation. To avoid technologies based on questionable corporate behaviour would be to discard most mainstream technologies including those from Microsoft, Apple, Google, IBM, Adobe, Oracle, and other large software companies. But Dirk had an important follow-up:

I don’t think MS is unique in getting crapped on by sectors of the development community. I see plenty of stuff that’s anti-Apple (platform lock-in – flash), anti-google (privacy), anti-IBM (patent whoring and before the PC era – anti-competitive behaviour), etc, etc.. MS has been a focal point of a lot of hate — more than the other companies you listed for sure — but I don’t think it’s irrational. I think it’s very good for developers to be thinking critically about the stakeholders behind the technologies they’re forced to use. I don’t think it makes much of a difference in investment decisions, but maybe it provokes discussion internally in the companies being criticized.

If a developer wants to criticize or boycott Microsoft for ethical reasons, I can respect that. What I cannot respect are the asinine statements like "IIS is garbage" or "C# and .NET suck." Those kinds of statements alienate developers from each other instead of fostering positive interactions and collaboration.

On a More Personal Note…

The past year or so has seen a steady decline in my use of the Microsoft development stack. The past 12 months has been more Python, PHP, and Java. I’ve also been using MongoDB and MySQL.

I was not renewed as a Microsoft MVP for 2011 because I was no longer actively participating in public discussions around .NET development. I also resigned from the Microsoft Regional Director program and from the INETA Membership Mentor program. Those decisions have a lot to do with some changes this past year in my professional trajectory and not any disenchantment with the Microsoft platform. I will share a few details if you’re interested (I won’t be offended if you stop reading here since the rest is pretty self-focused).

In 2002 I dropped out of graduate school and started a software company. The idea was to bootstrap product development with consulting revenue. But as has happened to countless other bootstrapped companies, we got addicted to the consulting revenue stream and the product development side of the shop floundered. We did release a product and it still has a loyal customer base but it didn’t grow the way we hoped.

Fast forward to the spring of 2010. I was still doing consulting work and managing the same software product. After 8 years I was tired of the recurring cycle of consulting engagements and too many nickel-and-diming clients. I was ready for a change. Through a fortuitously timed conversation, I found myself agreeing to become an employee of Radian6 and working on a technology stack other than the Microsoft platform that had been my bread and butter for 80% of a decade. (I also sold my house and moved my family to a new city so it was also a significant life change.)

I joined Radian6 in large part because of the cool web-scale challenges it tackles. Out here on the east coast of Canada there aren’t too many choices if you want to work on world-class web-scale technology. And conveniently I had a few friends and acquaintances already working there.

If the name Radian6 sounds familiar to you, it might be because salesforce.com just acquired the company for several hundred million dollars.

So why am I posting this here? Well, in part because I want to share my change of professional trajectory with you. But mostly I want to declare a few things:

  1. Ardent Dev continues to be my meager catalyst for conversation with fellow developers, architects, and IT professionals. The views expressed are mine alone. This entire experiment / evolution of blogging will remain fully independent.
  2. I won’t shill for Radian6 or salesforce.com here. If there is something amazing happening for developers at large, I may share it at my personal discretion but that’s it.
  3. My technology portfolio has expanded and while I continue to be a big fan of the Microsoft development stack, I spend far less time with it these days. I am more excited about the coolness of the technology I am building than the coolness of the technology I build it with.
July 27, 201113 commentsRead More
When is software done?

When is software done?

Are you done yet? Such a simple question…

Earlier in my career I worked on a project that went into production with what I would consider a less than optimal set of internal admin tools. We deployed it and handed it over to the client’s internal team where it stayed live but untouched. After a year in prod, I got an email from the client asking how to cancel a subscription. Apparently someone had signed up and wanted out but was unwilling or unable to use the self-serve features.

The building of software is a funny thing. You can be busy in most professions. You can have more work to do than you can possibly get done. You can have unrealistic deadlines. But you can achieve an outcome, mark it complete, and move on. Software is strange because there are different definitions of done and even when you think it’s done, it probably isn’t. Software components run for months or years with bugs, inconsistencies, performance problems, and security vulnerabilities.

Software developers are accustomed to being asked “when will you be done?” But the question presupposes a shared understanding of what “done” means. Different definitions of done can lead stakeholders to be disappointed in the progress and predictability of software teams. Managers recently promoted from the technical ranks may not have learned to factor in time for tasks beyond the initial code-and-test cycles.

We’ve all seen developers declare a piece of work complete because it compiles or because it ran once with some sample data without crashing. Computer science courses even encourage that behaviour with a constant barrage of coding assignments that are immediately discarded. Eventually professional developers learn the difference between code that runs and code that’s done.

Let’s explode that word done into some more granular stages:

1. The code is written

2. The code is tested

3. The functionality is documented

4. The code is secure, scalable, fault tolerant, and reliable

5. The code is ready to deploy

6. The code is in production

7. The code is no longer being updated (enhancements and/or bug fixes)

8. The code is no longer supported

9. The code is no longer being used

So, are you done yet?

February 14, 201115 commentsRead More
The Shameful Legacy of 20th Century Software

The Shameful Legacy of 20th Century Software

Last week I got to spend an evening reinstalling my wife’s laptop because she picked up some malware.  She received an email from a friend with a link to a YouTube video that prompted her to install a new codec.

Except the codec wasn’t really a codec.

The link wasn’t really to YouTube.

The email wasn’t really from her friend.

Here we are in 2010, 65 years after the advent of "program instructions as data" (von Neumann architecture) and the brilliant innovations that propelled computing forward now haunt us.  The power and complexity of computing is amplified by the connectivity of the Internet, creating an ecosystem ripe for exploitation through clever social engineering combined with some technical trickery.

And it’s not fair.  It’s not fair to the users who suffer, who lose data, whose systems are held hostage.  It’s not fair and the blame for calamities cannot be laid at the feet of careless or naive users.  Daily computing tasks should not require constant vigilance, let alone deep technical knowledge.

Many of us schooled in the last century hold on to notions of software that are simply unsafe for many of our users.  We insist on building software that must run in environments that are not inherently safe.  But there are trends afoot: the closed ecosystem of the iPhone and the iPad, the coming Windows Phone 7 closed ecosystem, and the increasing ubiquity of Internet applications.  Slowly but surely we are moving toward paradigms in which the average user will have much less to worry about because software is vetted and sandboxed.

As a developer I don’t want to be sandboxed in every situation.  I want to be able to make educated decisions about software and run it on my devices, but the default should be safe and secure.  It’s shameful that things are still so treacherous.

March 17, 201013 commentsRead More