The day everything changed

In my 20+ years in software, I've seen plenty of changes.  Exponential growth in computing power combined with maturation of tools, techniques, and frameworks has driven an inexorable march forward.  Most of these changes take the form of incremental improvements and industry trends.  Even though change is rapid compared to a lot of fields, it remains linear and gradual.  You might already be reading articles that look back at things we've seen in 2014 or look forward to trends expected for the coming year -- a byproduct of this sort of change is that it's most visible when viewed over a period of time.

But every once in a while, there are quantum events that redefine the landscape of technology -- transcending technology, in fact, to become part of our popular dialog.  The introduction of Windows 95, for instance, or the announcement of the first iPhone.  There are a handful of these events over the years where our landscape changed overnight.

Today was one of those days.

Embed from Getty Images

No i-device was announced today, though.  No new software empowered millions of users to be able to accomplish something they couldn't have dreamed of yesterday.  No, today, we saw an announcement from the FBI: For the first time, a case of truly harmful cyber-terrorism has been linked to a nation.

I'm talking about Sony, of course, and the hacking incident we've all been watching for the last few weeks.  In case you've been living under a rock, the incident began with a massive hack of Sony's systems, compromising emails, private information, intellectual property (including movies), and more.  The hackers almost immediately demanded that Sony cancel distribution of their upcoming film, "The Interview", leading to early speculation that the attacks originated from North Korea.  The hackers continued to rain blows down on Sony until Wednesday, when Sony finally capitulated by pulling plans to show the movie.

Today's announcement, though, while widely anticipated, signals a chilling new reality for all of us -- not just those of us directly connected to technology.  I believe we'll look back on the events of the last couple weeks as an awful watershed moment.  Everything just changed in a very scary way.

Recall the days immediately following the 9-11 attacks: I think the overwhelming majority of Americans were enthusiastically behind the idea that America needed to find someone's butt to kick, and kick hard.  As a global citizen, not to mention a member of the U.N. Security Council and the last remaining superpower on Earth, though, we as a nation were paralyzed by the fact that we couldn't find an actual nation to declare war against.  In lieu of a single well-defined war, we wound up heavily involved in military operations that still haven't seen a true conclusion, and I don't think most Americans feel like we've seen the sort of "closure" we'd have liked.  It turns out that chasing terrorists is a little like trying to nail snot to a tree.

The Sony hack is a little different, though, if it's true that this act originated with the North Korean government.  It's true that we've seen any number of highly suspect electronic invasions over the last few years in which nations (most notably, China) were suspected to play a part.  In these prior cases, though, the incursions were typically more properly considered espionage, and the nations suspected of these activities were just careful enough that nothing "real" ever stuck to them.  The Sony case, then, is a scary new milestone.

There's lots of dust left to settle in this case.  President Obama, for instance, has promised that action will be taken against those responsible for this attack, but we don't know yet what form that might take.  It's unclear how we'd expect a State to retaliate against another State for actions directed at a corporation, as well.  This is truly uncharted territory.  Not uncertain, though, is the impact of this incident - I'm quite confident we'll remember this week well into the future.

 

Adding insult to injury

Software developers are a clever lot, and prone to bouts of creativity every once in a while.  It turns out these are essential traits when building software, but cleverness also needs to be must be tempered when it impacts the user-facing parts of your software.

Please don't do this.
(Bugzilla's "no results found" message -- please don't do this)

Case in point:  Bugzilla's search results page.  This is what happens when you try searching for something in Bugzilla and it doesn't find any results.  It's supposed to be funny -- the misspelling is, in fact, intentional.

But it's not funny.  It's really, really not funny.  It's not funny for two very specific and very important reasons.

Reason 1: Usage context.  If any Bugzilla user ever sees this message, it's because he failed at the task he was trying to accomplish.  Since the message exists solely to explain to the user that he failed, it's pretty reasonable to assume that the user might not be in the best of moods already.  I know I wasn't.

Reason 2: Product context.  If you've not already had the pleasure of using Bugzilla, let me fill you in on its search capabilities: they suck.  Like, searching in Bugzilla is not only unpleasant, it's also unfruitful way too often.  It's the best reminder you're likely to see about why Google won the search wars -- it's because everything else used to work like Bugzilla.  So when your (otherwise excellent) product has a critical flaw, such as searching in Bugzilla, it might be best to not choose that specific part of your product to try to crack a funny.  Just sayin'.

The lesson in all this?  Somewhere on any product team, there needs to be a voice of reason who's looking at context stuff like this and deciding when it's time to be funny, and when it's not.

Issue Tracking Basics

Years ago, I introduced a bug tracking system at a software company, and the most lasting lesson I learned from that process has nothing to do with software.  You see, even though it took a while to accomplish this, I eventually trained our company to use this system to finally be able to answer the highest and greatest question of any operationally-oriented workgroup:

What the hell is going on?

It astounds me on a pretty regular basis how utterly lost people (and organizations) are with respect to this simple question, and I think it ultimately stems from people trying to relate to one another like people, rather than as parts of an organization.  While this is completely understandable -- even virtuous -- the uncertainty and passivity of polite society are inefficient and confusing. Ironically, the more polite everyone tries to be, the more tension builds as problems fester and grow.

IMG_6875_HDR.jpg
(Photo credit: lambertpix)

Like ripping off a band-aid, though, I've found that setting a few simple rules, and then sticking to them rigorously, so thoroughly squelches the confusion about "who's doing what" that the pain of working the system quickly gives way to the relief of actually knowing what the hell really is going on.

Before jumping into the rules, understand that this approach applies most directly to tasks in the context of an organization.  If you're unsure of the difference, here's a clue: if you're talking about something the organization would expect to get done even if the person who normally does it is sick or on vacation, then it's an organizational task.  If it's going to wait for you no matter how long you're out of the office, then you don't really need to bother with this at all -- just work your own to-do list.

So, without further ado, the rules:

  1. Have a list.  Use a whiteboard or a spreadsheet or scrabble tiles, but whatever you use, treat it as the one and only definitive source of truth and enlightenment for your organization (with respect to the subject of the list, of course).  Given that tools like Bugzilla are available for free, scrabble tiles would really be sort of silly, but the important part is that the list is kept sacred.  Better yet, tools that are built for this sort of thing will help enforce the rest of these rules.
  2. The list belongs to the organization, but assignments belong to people.  You're trying to map the somewhat nebulous idea of organizational responsibility to actions of individual people, so this part is important.
  3. Assignments belong to one and only one person.  When I talk about people being responsible for things, I'm talking about one person (I've covered this before, incidentally).
  4. Someone needs to be responsible for the list.  I'm not talking about items on the list -- I'm talking about the integrity and life-force of the list itself.  This is a full-time job, and it must be staffed all the time, so be ready to pass this baton when your list-owner is sick, on vacation, or out of the office.  Your organization will eventually self-train to keep the list alive, but this takes serious time and dedication (think years, not months or days).
  5. Issues belong to a single person.  Again, with the one and only one person.  It's important.
  6. Issues can change owners.  They should, in fact, or you're probably not talking about an organizational issue.  Most of the time, issues are created precisely because the person who finds the issue isn't the person who needs to do something about it.
  7. If it ain't in the list, it never happened.  Watch out for stuff happening "off the books".  I can't tell you how many times I experienced people sending an email about an issue because they didn't want to take the extra thirty seconds necessary to add something to the bug tracking system, but in return for saving those few seconds, your organization will give up all the management oversight and quality control your list gives you.  I personally saw the single worst "off-list" violator in my organization turn in to the biggest "list enforcer" over the course of a couple years because the list works.
  8. Ok, I lied.  Scrabble tiles suck.  In most cases, you really want a place to show history, emails, attachments, and so on, because most issues complicated enough to need a system gather little artifacts like this as they're worked, and if it ain't in the list, it never happened.  One of the points of tracking stuff in the list instead of email is that as these issues pass from one person to the next, the list holds the whole thread and context of the issue – very unlike email, where information goes to die.
  9. A quiet list is a dead list.  If you don't see activity in the list, it sure as hell doesn't mean there aren't any issues.  It means nobody's using the list.  The list owner should have a good enough sense for the "pulse" of issues to know if this ever happens, by the way.
  10. A quiet issue is a dead issue.  Sounds familiar, no?  If there's no action on an issue, somebody needs to know why.  If nobody cares about it all that much, make sure it gets shunted to a side track of some sort, but if it's an issue that needs to be dealt with, find out why it's stalled and address the problem.  This is "project manager 101" stuff, but it's really easy to miss unless you've got a living list, and really hard to miss if you're really working a list.

There's more you can do with issue tracking once you get this far, but I promise if you embrace the rules here in a meaningful way, your entire organization will take a step up in efficiency and effectiveness, and best of all, you'll eliminate a whole lot of the latent tension that comes from trying to manage implicit lists.

 

 

The politics of software

This fall, as healthcare.gov imploded before our eyes, we saw any number of self-proclaimed experts chime in on why it coughed, sputtered, and ground to a halt, and how, exactly, it might be fixed.  My guess is that the answer is more complicated than most of them let on, but I'll bet there's a healthy dose of politics mixed in with whatever technological, security, and requirements issues might have surfaced along the way.

IMG_6589.jpg

It seems somewhat counter-intuitive to talk about politics at all in the context of software development, of course.  One of the aspects of software that really appealed to me when I entered this field was that for most problems, there existed an actual correct answer, and there are no politics in algorithms.  Ah, to return to the halcyon days of simple problems and discrete solutions!

Today's problems are more complicated than ever before, though.  Prodigious capabilities have bred complex systems and murky requirements under the best of circumstances, and no government project operates under the best of circumstances.  For those of you in private enterprise, you surely are aware of the struggles bred of competing interests and limited resources, but in a government setting, all those factors explode.  Funding is rarely connected directly to stakeholders, opinions are everywhere, and "deciders" are nowhere to be found.   Not to put too fine a point on this, but if we were to think of government-sponsored software as having been congealed rather than developed, we might be on the right track.  It's actually a small miracle when these systems work at all, given the confluence of competing forces working to rip projects in seventeen directions at once.

Think back for a moment on the early days of Facebook or Twitter or any of the other massive applications that serve as today's benchmarks of reliability.  They weren't always so reliable, of course.  Twitter, in particular gave birth to a famous "fail whale" meme in 2009 as it sorted out its capacity and reliability issues.  To be clear, twitter operates on a huge scale, but all it's doing is moving 140-character messages around -- there isn't a whole lot of business logic there, short of making sure that messages get to the right person.  It's pretty easy to gloss over some of those growing pains, but virtually every large system has them.  In the case of healthcare.gov, the failures happened under the hot lights of opening night and amid opponents who wanted desperately to see the system fail, and fail hard.

If you work amid politics like this, I'd love to offer a simple solution, but sadly, I have none.  Instead, I'd urge a little empathy; walk a mile in the footprints of developers, project managers, analysts, and testers on projects like this before you criticize too vigorously.  I can assure you that if you think this was a failure with a simple cause, you're mistaken.

Related articles

 

 

Enhanced by Zemanta

Microsoft still struggling to put pieces together

I've been a Microsoft developer for a lot of years now.  As such, I'm intrinsically motivated to want to see them succeed.  For that reason, it's painful to see what's become of the Microsoft juggernaut.  Office hasn't given us a meaningful improvement since somewhere around Office '97.  Windows fared a little better, probably due in no small part to the dismal showing of Vista, which made Windows 7 look like a breath of fresh air.  Despite this, I still think Microsoft fields the best set of developer tools, top to bottom, of anyone, and I'd love to keep developing solutions with them.

Microsoft Office Mobile on Windows Phone
Microsoft Office Mobile on Windows Phone (Photo credit: Wikipedia)

As a fan of Microsoft, then, I'd love to see Windows 8 take off -- on the desktop, tablets, phones -- everywhere, but it's not, and I don't have to look to far to understand why.  I recently upgraded three machines at home from Windows 7 to Windows 8, and I have to admit that the tablet features appear to have been duct-taped onto Windows 8 with little regard to optimizing the experience for either type of client.  I can only imagine what the phone experience is like.  I'm still finding myself at a loss for where various bits and pieces have wandered off to.  Thank God for search, or I very well might have downgraded by now.

Worst of all, there are signs that Win 8's problems are a bit more widespread than my own personal adoption headaches.  Well-known developer evangelist Rocky Lhotka wrote a post this week addressing licensing headaches that could very well keep enterprise customers from adopting WinRT for internal applications, and MVP John Petersen wrote about the continued lack of applications for Windows 8.  Are these problems affecting Microsoft's bottom line?  It may be too early to call, but reports indicate that Microsoft is cutting prices on Windows and Office, and that's not a good sign.

As far back as I can remember, Microsoft has been king of the "platform".  They've always understood that there's a synergistic relationship between OS, applications, developer tools, and users.  It's possible to be successful successful in one or two of these areas, but if you're able to leverage success in one area to grow in another, the leverage is tough to beat.  It's too late for Microsoft to win mobile by meeting Apple or Android in a heads-up battle.  Same goes for tablets.  If Microsoft hopes to be relevant again (let alone dominant), they need a holistic solution that blows open a market that Apple and Google don't already own.

So, what's left?  Unfortunately, there's very little obvious green field left, but the one real hunk of market where Microsoft actually holds the high ground is entertainment -- namely, Xbox.  Sadly, Microsoft has been running Xbox like its own little company since Day 1, so although it works really well with Windows, there's so much more synergy to be had in home computing and entertainment if Microsoft would merely re-assemble pieces and parts they already own into a platform that would actually add value in the home.

Curious?  Stick around -- next time, I'll lay out the product that could save Microsoft if they'd just break down some walls and build it!

Enhanced by Zemanta