DaedTech

Stories about Software

By

Software Architect as a Developer Pension Plan

I’m pretty sure that I’m going to get myself in trouble with this one.  Before I get started and the gnashing of teeth and stamping of feet commence, let me offer an introductory disclaimer here.  What I am about to say offers no commentary on people with the title, “software architect” (a title that I’ve had myself, by the way).  Rather, I offer commentary on the absurd state of software development in the corporate world.

The title “software architect” is silly (mostly because of the parallel to building construction) and the role shouldn’t exist.  Most of the people that hold this title, on the other hand, are smart, competent folks that know how to produce software and have the battle scars to prove it.  We’ve arrived at this paradoxical state of affairs because of two essential truths about the world: the corporation hasn’t changed much in the last century and we software developers have done an utterly terrible job capitalizing on the death grip we have on the world’s economy.

Architect

A Question of Dignity

I’m not going to offer thoughts on how to correct that here.  I’m doing that in my upcoming book.  Today, I’m going to answer a question I heard posed to the Freelancer’s Show Podcast.  Paraphrased from memory, the question was as follows.

I work for a small web development firm.  I was in a meeting where a guy said that he’d worked for major players in Silicon Valley.  He then said that what web and mobile engineers offer a commodity service and that he wanted us to serve as architects, leaving the less-skilled work to be done by offshore firms.  How does one deal with this attitude?  It’s a frustrating and demeaning debate to have with clients.

This question features a lot that we could unpack.  But I want to zero in on the idea of breaking software work into two categories: skilled work and unskilled work.  This inherently quixotic concept has mesmerized business people into poor software decisions for decades.  And it shows no signs of letting up.

Against this backdrop, “major player’s” attitude makes sense.  Like the overwhelming majority of the business world, he believes the canard about dividing work this way.  His view of the unskilled part as a commodity that can be done offshore smacks of business wisdom.  Save the higher-waged, smart people for the smart people work, and pay cheap dullards to do the brainless aspects of software development.

Of course, the podcast listener objects.  He objects to the notion that part of what he does fits into the “cheap commodity” category.  It “demeans” him and his craft.  He understands the complexities of building sites and apps, but his client views these things as simple and best delegated to unskilled grunts.

Why the Obsession with Splitting Software Work?

It bears asking why this thinking seems so persistent in the business world.  And at the risk of oversimplifying for the sake of a relatively compact blog post, I’ll sum it up with a name: Taylor.  Frederick Taylor advanced something simultaneously groundbreaking and mildly repulsive called Scientific Management.  In short, he applied scientific method principles to the workplace of the early 1900s in order to realize efficiency gains.

At first, this sounds like the Lean Startup.  It sounds even better when you factor in that Taylor favored more humanizing methods to get better work out of people than whacking them and demanding that they work harder.  But then you factor in Taylor’s view of the line level worker and you can see the repulsive side.

The labor should include rest breaks so that the worker has time to recover from fatigue. Now one of the very first requirements for a man who is fit to handle pig iron as a regular occupation is that he shall be so stupid and so phlegmatic that he more nearly resembles in his mental make-up the ox than any other type. The man who is mentally alert and intelligent is for this very reason entirely unsuited to what would, for him, be the grinding monotony of work of this character. Therefore the workman who is best suited to handling pig iron is unable to understand the real science of doing this class of work.

Basically, you can split industry into two camps of people: managers who think and imbeciles who labor.  Against this backdrop, the humanizing angle becomes… actually sorta dehumanizing.  Taylor doesn’t think grunts shouldn’t be whipped like horses because it’s dehumanizing, but because it’s not effective.  Better ways exist to coax performance out of the beasts.  Feed them carrots instead of hitting them with sticks.

Depressingly, the enterprise of today looks a lot like the enterprise of 100 years ago: efficiency-obsessed and convinced that middle management exists to assemble humans into bio-machines that needn’t think for themselves.  Nevermind that this made sense for assembling cars and textile manufacture, but not so much for knowledge work projects.  Like the eponymous cargo-culters, modern corporations are still out there waving sticks around in the air and hoping food will drop out of the sky.

Read More

By

Defining Developer Collaboration

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at the pieces written by other authors as well.

A certain ideal of rugged individualism has always permeated programmer culture, at least in some circles. It’s easy enough for writing code to be a highly solitary activity. There’s a clear set of rules, output is a function of input, feedback is automated, and the profession tends to attract night owl introverts in many cases.

The result is a history punctuated by tales of late night, solo efforts where someone stares at a computer until overcome by sleep. Obsessed, brilliant hackers expend inconceivable efforts to bring amazing open source tools or useful libraries into existence. It squares with movies, popular culture, and our own knowledge of our profession’s history.

SuperFastTyping

And yet, how many significant pieces of software are developed this way anymore? This ideal was born into a world where complex software might have required 10 thousand lines of code, but does it carry forward in a world where 10 million lines are common? Even projects started by individuals on a mission tend to wind up on Github and to gather contributors like a snowball rolling down a mountain.

Today’s technical landscape is a highly complex, highly specialized, and highly social one. In a world where heroic individual contributions are increasingly improbable, collaboration becomes the name of the game. Like it or not, you need other people to get much done because the work and the breadth of knowledge tends to be too much for any one person.

Defining Collaboration for Developers

I’ll spare you the obligatory, “Webster’s Dictionary defines collaboration as…” It means what you think it means: people working together. I’d like, instead, to establish some axiomatic ground rules in applying the term to the world of software development.

The first requirement is, of course, that you need to have more than one human being involved to consider the effort to be collaboration. The mechanisms, protocols and roles can vary widely, but table stakes require more than one person.

The second requirement is that the participants be working toward a shared goal. Without this, a bunch of people in a coffee shop could be said to be ‘collaborating’ simply by virtue of colocation and the occasional, polite interaction. Collaboration requires multiple people and it requires them to be united in purpose for the activity in question.

A final and developer-oriented requirement is that the participants must be working on the same work product (i.e. codebase). Again, consider a counter-example in which iOS and Android developers could be said to be ‘collaborating’ since there are more than one of them and they’re united in the purpose of improving users’ smartphone experience. Their shared purpose has to bring them together to work on the same actual thing.

Really, though, that’s it. More than one person, united in purpose and working on the same thing, are necessarily collaborating. Whether they do it well or not is another matter.

Read More

By

How to Get Developers to Adopt a Coding Standard

Editorial Note: I originally wrote this post for the NDepend blog. Head over to their site and check out the original, here.  While you’re there, have a look around at the other posts; if you enjoy static analysis, you’ll enjoy what’s there.

If you’re a manager, there’s a decent chance that the subject of coding standards makes you want to bang your head against a wall repeatedly.  If you’re a developer, you can probably understand why this is true of your manager, if you think about it.

The group coding standard has the following properties.

  • It’s extremely technical and granular.
  • Developers tend to squabble about it.
  • If it produces any business value, it does so obliquely and theoretically, from management’s perspective.

Thus, if I’m a manager, there’s this inscrutable document out there that causes my team to argue, and whose existence I must take on faith to be a good thing.  As you can see, it doesn’t start out on my good side.

Does It Matter?

There are all manner of opinions and arguments to be found on the internet as to why a coding standard matters (or doesn’t).  I’ve wrote about the subject myself from time to time.  So, without belaboring the point, I’ll make the quick business case for it.

The purpose of a coding standard, at its core, is twofold:

  1. It promotes maintainability by making all code look similar and familiar to all developers.
  2. It standardizes approaches that promote correct code (and avoid incorrect code).

Thus, on the whole, the coding standard makes the total cost of ownership of the codebase decrease by some amount ranging between 0 and “indeterminate.”  As an outside party, you simply have to take on faith that there is an ROI and that the amount of time wasted in arguments, complaining, and compliance is offset by the reduced troubleshooting and onboarding times.

And, in my experience, it generally is.  Notwithstanding pouting and bickering that happens early in the project and makes life unpleasant, it’s better to have these things than not to have them.  The key, then, becomes minimizing the cost of having the standard.  And you do this by securing compliance with the least amount of heartburn for all involved.

So how do you do that?  How do you convince the developers to buy in with a minimum of resistance and friction?

Clipboard

Read More

By

How Code Review Saves You Time

Editorial note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at their offering.

Physical labor is one of the most strangely enduring mental models for knowledge work.  Directors and managers of software development the world over reactively employ it when nudged out of their comfort zones, for instance.  “What do you mean ‘pair programming’ — we’ll get half of the work done for the same payout in salary!”  And that’d be a reasonable argument if the value of software were measured in “characters typed per minute.”

WorkHarder

Most of the skepticism of activities like unit testing and code review originates from this same “knowledge work as labor” confusion.  The core value of software resides in the verbatim contents of the source code files, so stuffing all of the features in them ahead of the deadline is critical.  Testing and reviewing are “nice-to-haves”, time and budget permitting.

The classic response from people arguing for these practices is thus one of worth.  It goes something like this: “sure, you can cut those activities, but your quality will dip and there will be more escaped defects.”  In other words, these ‘extra’ activities pay for themselves by making your outfit look less amateurish.  That argument often works, but not always.  Some decision-makers, backs truly to the wall, say “I don’t care about quality — my job depends on shipping on June 19th, and we’re GOING to ship on June 19th, whether it’s a finished product or whether it’s a bag of broken kazoos and cyanide with a bow on it.”

I’d like to take a different tack today and fight a time argument with time arguments.  Instead of “sure, code reviews take extra time but they’re worth it,” I’d like to explore ways that they actually save time.  Whether they save more time than take is going to vary widely by situation, so please don’t mistake my intent; I’m not looking to argue that they’ll save you net time, but rather that they are not exclusively an investment of time.

Read More

By

How to Actually Reduce Software Defects

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Have a look around while you’re there and see what some of the other authors have written.

As an IT management consultant, probably the most frequent question I hear is some variant of “how can we get our defect count down?” Developers may want this as a matter of professional pride, but it’s the managers and project managers that truly burn to improve on this metric. Our software does thousands of undesirable things in production, and we’d like to get that down to hundreds.

Fumigation

Almost invariably, they’re looking for a percentage reduction, presumably because there is some sort of performance incentive based on the defect count metric. And so they want strategies for reducing defects by some percentage, in the same way that the president of the United States might challenge his cabinet to trim 2% of the unemployment percentage in the coming years. The trouble is, though, that this attitude toward defects is actually part of the problem.

The Right Attitude toward Defects

The president sets a goal of reducing unemployment, but not of eliminating it. Why is that? Well, because having nobody in the country unemployed is simply impossible outside of a planned economy – people will quit and take time off between jobs or get laid off and have to spend time searching for new ones. Some unemployment is inevitable.

Management, particularly in traditional, ‘waterfall’ shops, tends to view defects in the same light. We clearly can’t avoid defects, but if we worked really hard, we could reduce them by half. This attitude is a core part of the problem.

It’s often met with initial skepticism, but what I tell these clients is that they should shoot for having no escaped defects (defects that make it to production, as opposed to ones that are caught by the team during testing). In other words, don’t shoot for a 20% or 50% reduction – shoot for not having defects.

It’s not that shooting for 100% will stretch teams further than shooting for 20% or 50%. There’s no psychological gimmickry to it. Instead, it’s about ceasing to view defects as “just part of writing software.” Defects are not inevitable, and coming to view them as preventable mistakes rather than facts of life is important because it leads to a reaction of “oh, wow, a defect – that’s bad, let’s figure out how that happened and fix it” instead of a reaction of “yeah, defects, what are you gonna do?”

When teams realize and accept this, they turn an important corner on the road to defect reduction.

Read More