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.
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.
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.
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:
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.
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.
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).
Issues belong to a single person. Again, with the one and only one person. It’s important.
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.
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.
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.
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.
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.
I was asked recently to define “craftsmanship” in software development, and I thought this would make a great topic for discussion. You can obviously find a dictionary definition for craftsmanship, but much like with architecture, I think that when we attach the additional context of software development, craftsmanship introduces some important ideas about how individual contributors fit into a larger software development organization.
Software as Art
The concept of craftsmanship in general emphasizes the skills of individuals, and connotes high-quality, highly customized work. It is very much the antithesis of mass production.
This general understanding, when applied to software development, implies a very individualized experience — indeed, if you think about buying a work of art or even something like a piece of furniture, “craftsmanship” would imply that the product you’re buying is one-of-a-kind. Nobody, literally, has another item quite like the one you’re buying. For businesses commissioning custom software, there’s a nugget of truth here, of course — one of the reasons to write custom software is the presumption that your business requirements are different in some way from everybody else’s requirements, and your business demands the flexibility that comes with custom software.
Another key aspect of craftsmanship is the deep and broad skill set of the craftsman. Just as you’d expect a hand-crafted product to be almost entirely the result of one man’s work (to the extent that signing the work wouldn’t be unheard-of), so software craftsmanship emphasizes individual skill and accountability. And while craftsmanship doesn’t necessarily imply apprenticeship, a craftsman is certainly expected to be highly experienced and able to draw on years of work in the field in order to produce the sort of high-quality work that’s expected.
While high-quality, highly-customized software sounds very appealing from a business perspective, the deliberate pace and unyielding attention to detail we most often associate with craftsmanship is petrifying. Business software needs to move at the pace of business, after all, doesn’t it? I really believe that the implied slowness of craftsmanship acts as an impenetrable stigma against its adoption, which I think is largely unfortunate.
One of the key benefits of the higher-quality code produced by accomplished craftsmen is that less time is spent on an ongoing basis recovering from the sins of shoddy coding as these systems grow and evolve over time. High-quality code not only works better, it’s more maintainable, so that initial effort can pay real dividends over the life of a long-lived system. Where we sometimes talk about sloppy code as being high in technical debt, quality code can be seen as an asset for an organization.
Right now, software craftsmanship remains on the fringe of development practices, and thus tends to be favored in smaller shops, as well as in “green-field” projects much more so than in larger, more established environments. It remains to be seen whether it eventually transitions into mainstream use the way that Agile has, but I think a lot depends on the effective communication of the real benefits of craftsmanship, as well as on mature tactics to introduce and manage craftsmanship in the organization.
Craftsmanship is about individual contribution. It’s about taking pride in your work, and it’s about a relentless journey of improvement. The scope of these experiences is best-suited to small groups of developers who can help one another grow and hold each individual accountable to the group. This, all by itself, is a tall order. It’s not easy for anyone to expose himself to criticism, and that’s a huge prerequisite for this sort of culture to form. This sort of open sharing takes huge amounts of trust, and trust takes time to build.
Another critical motivator for a “craftsman-like” organization is the sense that the team is building something that’s going to last. When you think of hard goods built by craftsmen, you equate the higher quality to a longer lifespan — as a consumer, you may be willing to pay a premium for a product that will outlast a cheaper product because you know it’ll last a long, long time. In software, this understanding of quality has to be visible to the team as well as the customer, and the team needs to believe that this higher quality is valued. Few things are as demotivating for a developer as seeing a great body of code mangled by someone who doesn’t share the same capabilities or desire for quality.
It might seem at this point that I’m advocating an all-or-nothing strategy for software development, or that software craftsmen can exist only in small shops, but I don’t believe either of these is necessarily true. I believe that if craftsmanship is going to exist in a large organization, however, the organization needs to understand where it’s going to be applied and it must organize its teams to support craftsmanship in targeted areas. I think this prerequisite is well-suited to a component-based Enterprise Architecture, in which well-defined components or services are identified, invested in, maintained with care, and protected, and yes — this demands an enlightened and skilled application of Enterprise Architecture.
Craftsmanship isn’t a magic wand, or a buzzword, or a slogan. Craftsmanship takes hard work, and it demands commitment from organizations and developers. It’s not right for every organization, and it certainly isn’t right for all developers, but if you need software that stands the test of time, craftsmanship will pay dividends for the lifetime of that software.
I’m not sure how I missed this up till now, but Microsoft is apparently looking into the same home automation space that Google is trying to gobble up with its Nest acquisition. Microsoft’s project (still in their research lab) is called HomeOS, with an accompanying software kit for devices called Lab of Things.
I’m really not sure whether to laugh or cry yet, because having long been a proponent of Microsoft to go kill this market, it really seems like they’re still missing the real bread & butter features needed to start printing money. I watched the demo video on the HomeOS page, and just about the whole damned demo is about seeing appliances blink on and off in response to arbitrary events — all on a Windows phone, of course. They finally touched on user access at nine and a half minutes into the ten-minute video, despite that being arguably the most important feature of all.
So listen, Microsoft — if there’s anyone out there still interested in making money, here’s how you do it.
HomeOS (or whatever this product winds up being called) needs a form of ActiveDirectory. One place — for real — to set up and administer users, including extended family members, friends, guests, etc. — with a single interface so I can light up guest WiFi and TV streaming for a guest, for instance, without needing to hit four or five different devices. Once this is in place, I promise I’ll never buy another device that doesn’t authenticate against this directory, ok?
Speaking of devices, I’m actually way less concerned about electronic doorbells than I am about XBoxes, NAS devices, and routers. Get this stuff to work together really, really seamlessly, and you might single-handedly save BestBuy.
Continuing on the theme of devices, I’ll repeat my recommendation to buy Drobo. Host your HomeOS on it, including AD, and package it to look like (and live next to) an XBox, including high-speed interconnection. BOOM! Microsoft owns the living room. The damned thermostat is an afterthought after that, you know?
Let me tunnel to the HomeOS box I buy for Mom & Dad. They’re not going to administer their own smart home, even if they can accomplish incredible things in less than 250 lines of C#. (Are you kidding me??? Is that *really* a feature??)
If you’re going to let me tunnel to other HomeOS locations, it’s a pretty short leap to go ahead and buy a router company, too, isn’t it? Plug that bad-boy right into my X-Drobo-thing, and configure it from the same interface. Make it easy enough for my nephew to set up, and keep it secure, too, if you think you can pull that off. That’d be great.
If you require me to use a Windows phone to use all this warm fuzziness, you can flush it all down the pot. You’re too late on this one, and you’re going to have to embrace Android and maybe even IOS. You should have listened to me earlier on that one.
Seriously, Microsoft — if you manage to snatch defeat from the jaws of victory on this one, I’m not going to feel too sorry for you. This should be a big ‘ol gimme — just by re-assembling some tech you’ve already got. Give it a shot — I’ll bet there’s plenty of time to sell brilliant doorbells later.
Each time a new software development trend appears, people manage to find a way to misinterpret it so that it looks like a shortcut — typically, because this is far easier than really understanding the idea in the first place. Invariably, these shortcuts fall flat on their faces — perhaps contributing to the “trough of disillusionment” in Gartner’s hype cycle. I saw this when people did procedural coding in an object-oriented language and called it OO, and I saw it when people thought they were “agile” just because they had a daily stand-up meeting. I’ve even seen it when the stand-up meeting was held sitting down.
Now, it’s DevOps. In much the same way as Agile doesn’t mean you don’t have to understand software requirements, DevOps doesn’t mean that you’re getting rid of your Operations team because your developers are doing their jobs for them. In “DevOps: The Future Of DIY IT?“, readwrite points out a Gartner survey that shows that NoSql databases are generally being administered by developers — not DBA’s — and projects out of this a future in which developers are running everything in production.
There are a couple of gigantic holes in that argument, though. First, I’d bet that if companies had DBA’s that knew the first thing about administering a NoSql database, they’d put them to work. Instead, these tools are so new and so immature that the tooling is still be invented, to say nothing of procedures. The second big problem with this over-generalization is that when developers are administering NoSql databases (or any other production systems), they’re not developing applications, quickly leading to a very expensive Operations staff.
That ain’t what DevOps is all about.
The goal of DevOps is to see developers and operations working together to create a virtuous feedback loop — just because they start acting like they’re on the same team doesn’t mean that either of them are going away.
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.
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.
I still believe quite strongly that a well-targeted home computing platform is just a couple of software tweaks away for Microsoft. Today’s edition is all about authentication. I’ve got a bunch of PC’s at home, including some VM’s. I’ve also got a Drobo 5N and a PS3 and a bunch of networking equipment.
You know what stinks? I need to set up logins on every single one of these devices individually, and they’re not connected to one another (so “Fred” on one box isn’t really the same login as “Fred” on another box).
Microsoft, give me a lightweight Active Directory for the home — something I can obtain without buying a Windows Server license, okay? Here’s a hint: if you built this into thew new XBox, I’d buy one, and I bet a bunch of other people would, too. Let me use this for DNS, so I can type “router” into my browser and actually get my router, instead of making me set up a HOSTS file on every single PC I own. By the way, how many average consumers would even know that’s possible??
I fully expect that the new XBox, when it arrives, will let me stream photos and music off my Drobo, but if you want to really take this idea to the next level, how about selling us a Pogoplug -type of device I can give to my Mom & Dad so I can (1) set up user names for them, and (2) let them see photos that I don’t plan on uploading to Flickr, etc.? The idea here, by the way, since I’m spelling everything out in excruciating detail, is that just about every family has one or more members somewhere who (a) own a gaming system, and (b) understand enough about computers to be the family SysAdmin.
Oh, and by the way, since you’ve given up on Windows Home Server for reasons I’ve never quite been able to fathom, and since you now aspire to be a “devices + services” company, why don’t you just go ahead and buy Drobo and make their stuff work with yours? I’d happily plug mine into a new XBox.
I swear, if Microsoft were able to get their collective heads out of whatever orifices they’re lodged within long enough to make an XBox that actually acted like it was part of a family, they’d crank up another WinTel-style monopoly to last them a good dozen more years.
It’s spring, 2013, and Intel has just released its Haswell processors and chipsets. Motherboard vendors are touting their new wares and all the manufacturers are announcing new products. As luck would have it, it’s about time to refresh workstations in our office, too, so it’s a fine time to take stock of the current state of the art for desktop systems.
So, without further ado, if you’re a developer, you want a system along these lines:
Intel Core i7 — Haswell is great, but Ivy Bridge would be fine.
At least 16 GB RAM.
An SSD boot drive – 128-256 GB.
Mirrored 7200rpm data drives – around 2-3 TB.
Integrated graphics are ok unless you do any serious graphics work.
As an aside, I checked my notes from 2009, and these are almost identical to the specs I put together the last time I looked at systems. We’ve gone through a couple generations of CPUs and chipsets, and the “sweet spot” for storage buys about double the capacity now, but the rough idea is about the same. I figure the cost for a system like this is down a third since then, too.
Incidentally, if you’re a professional in a content-generation field (web design, illustration, photography, video), this is a decent starting spot for you, too, though you’ll probably want to toss in a stout video card to help with the graphics. Although you might be tempted to save a few bucks here or there, every single one of these elements is there because it adds value for a professional who relies on his equipment. Nothing about this configuration is exotic or surprising.
Despite this, I continue to be astounded that nobody sells systems that look like this. Obviously, you can build it yourself, and if you know the first thing about computers, I highly recommend this — you’ll wind up getting better parts, and there’s something to be said for knowing your kit is built right. Some shops would obviously rather buy PC’s than pay people to assemble them, though, and so it is here. Off to Dell.com, then.
Before I start ripping Dell, I’ve got to point out that I’ve generally been a fan of theirs. I’ve used something approaching dozen of their PC’s and laptops at work over the years, and I’ve got a Dell laptop at home that’s recently been retired because it stopped charging. I used to have a Dell 1U server in my basement running VM’s, in fact. Noisy, but a nice little machine. I’ve got no ax to grind with Dell, per-se. Despite this, they’re dead to me now.
I’ve always found their product lines to be a bit too complex, and their configurator is just about as much fun as a poke in the eye with a sharp stick. I’d forgotten about this, but I shopped their site back in 2009 to see if they could build a system along the lines I indicated up front. They couldn’t. Back then, this was disappointing, but not terribly surprising. Intel’s RAID-enabled chipsets were fairly new, so practical mirroring was fairly novel, and SSD’s were just beginning to trickle down from enthusiast systems. Today, both of these things should be considered absolutely mainstream. I honestly don’t understand how both of these features aren’t considered standard equipment for anyone who makes more than minimum wage.
On top of not being able to build the system I wanted, the web site absolutely blew chunks. As soon as I visited the site, I got one of those “Will you leave your opinion?” pop-ups, and every time I selected a system, the page scrolled over to the top-right, where a “Chat with Dell” window appeared, offering me help. Offer accepted. Needless to say, “Brandon” wasn’t able to help me: “…and no workstations that we have will allow an SSD boot hard drive and then mirrored 2nd and 3rd hard drives.” No kidding. I also participated in their feedback session. At the end, they asked if I had any additional notes for them. I did:
The last time I tried shopping for a system here was 2009. At that time, I was looking for a Core i7 desktop with around 16GB RAM, an SSD boot drive and mirrored data drives. I couldn’t find one. Today, I tried shopping for the same thing, and guess what — can’t get there from here. This is a standard configuration for developers, and you literally can’t buy it from Dell. You guys might want to worry a little less about how your buyout is going and more about building PC’s. Just sayin’.
So, that was Dell. The good news is that HP fared better. I opened the site without drama, and found a desktop right off the bat that would support the configuration I wanted. The system I wound up configuring used an Ivy Bridge processor instead of Haswell, but at least I could get something close. Dell, I know you probably sell far more PC’s to secretaries and call center workers than you do to developers, but if you don’t hold the high ground, you’re going to get your head handed to you on commodity systems.
Have you ever experienced a cascading menu that seemed to run away from you as you navigated it? This is one of those subtle usability failings that can lead to a disembodied hatred of a site or application. Very few people will notice what’s actually going wrong, let alone what should be done to fix it.
The moral of the story? When you get this stuff right, most people never notice the details, but they’ll notice the feeling of quality in the product. Nobody loves an Apple iAnything because the edges are chamfered exactly so or because the icons are rounded just a bit, but they notice that it feels solid and sorted out. I’ll bet you’d have a hard time finding people who can tell you exactlywhy a BMW feels better than a Chevy, but most of them will agree that it does.
As a designer, it’s important that you do, in fact, notice the little stuff, and that you understand how these details contribute to the quality of your product. With any luck at all, you’ll work for an organization that also gets this stuff, because you’ll also find it pretty frustrating to try to explain details like this to a bean-counter that hasn’t got any awareness of this relationship.
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.
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.
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!