DaedTech

Stories about Software

By

How to Get Coding Standards Right (and Wrong)

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and give it a try!

Nothing compares with the first week on a new job or team.  You experience an interesting swirl of anticipation, excitement, novelty, nervousness, and probably various other emotions I’m forgetting.  What will your new life be like?  How can you impress your teammates?  Where do you get a cup of coffee around here?

If you write code for a living, you know some specific new job peculiarities.  Do they have a machine with runnable code ready on day one?  Or do you have to go through some protracted onboarding process before you can even look at code?  And speaking of code, does theirs square with elegant use of design patterns and unit testing that they advertised during the interview process?  Or does it look like someone made a Death Star out of bailing wire and glue?

But one of the most pivotal moments (for me, anyway) comes innocuously enough.  It usually happens with an offhand comment from a senior developer or through something mentioned in your orientation packet.  You find yourself directed to the coding standards document.  Oh, boy.

At this point, I start to wonder.  Will I find myself glancing at a one-pager that says, “follow the Microsoft guidelines whenever possible and only include one class per file?”  Or, will I find something far more sinister?  Images of a power-mad architect with a gleam in his eye and a convoluted variable name encoding scheme in his back pocket pop into my head.  Will I therefore spend the next six months waging pitched battles over the placement of underscores?

Ugh, Coding Standards

In this post, believe it or not, I’m going to make the case for coding standards.  But before I do so, I want to make my skepticism very clear.  Accordingly, I want to talk first about how coding standards fail.

Based on personal battle scars and my own experience, I tend to judge coding standard documents as guilty until proven innocent.  I cannot tell you how many groups I have encountered where a coding standard was drafted, “just because.”  In fact, I’ve even written about this in the past.

Read More

By

Measure Your Code to Get Back on Track

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.

When I’m called in for strategy advice on a codebase, I never arrive to find a situation where all parties want to tell me how wonderfully things are going.  As I’ve mentioned before here, one of the main things I offer with my consulting practice is codebase assessments and subsequent strategic recommendations.

Companies pay for such a service when they have problems, and those problems drive questions.  “Should we scrap this code and start over, or can we factor toward a better state?”  “Can we move away from framework X, or are we hopelessly tied to it?”  “How can we evolve without doing a forklift upgrade?”

To answer these questions, I assess their code (often using NDepend as the centerpiece for querying the codebase) and synthesize the resultant statistics and data.  I then present a write-up with my answer to their questions.  This also generally includes a buffet of options/tactics to help them toward their goals.  And invariably, I (prominently) offer the option “instrument your code/build with static analysis to raise the bar and prevent backslides.”

I find it surprising and a bit dismaying how frequently clients want to gloss over this option in favor of others.

Using the Observer Effect for Good

Let me digress for a moment, before returning to the subject of preventing backslides.  In physics/science, experimenters use the term “observer effect” to describe an experimental problem.  This occurs when the act of measuring a phenomenon changes its behavior, inextricably linking the two.  This presents a problem, and indeed a paradox, for scientists.  The mechanics of running the experiment contaminate the results of the experiment.

To make this less abstract, consider the example mentioned on the Wikipedia page.  When you use a tire pressure gauge, you measure the pressure, but your measurement lets some of the air out of the tire.  You will never actually know what, exactly, the pressure was before you ran the experiment.

While this creates a problem for scientists, businesses can actually use it to their advantage.  Often you will find that the simple act of measuring something with your team will create improvement.  The agile concept of “big, visible charts” draws inspiration from this premise.

In discussing this principle, I frequently cite a dead simple example.  On a Scrum team, the product owner has ultimate responsibility for making decisions about the software’s behavior.  The team thus needs frequent access to this person, despite the fact that product owners often have many responsibilities and limited time.  I recall a team who had trouble getting this access, and put a big piece of paper on the wall that listed the number of hours the product owner spent with the team each day.

The number started low and improved noticeably over the course of a few weeks with no other intervention at all.

Read More

By

The Pyramid Corporation: Your Grade School Teacher for Adults

I can now proudly say that I have finished the initial draft of Developer Hegemony.  Currently, it weighs in at a robust 376 pages that contain my blood, sweat, and tears.  Digitally speaking, anyway.

I haven’t yet published the preview of it because I want to give the people I interviewed a chance to peruse the draft before I make their words available.  But I promise that you’ll have a chance to read in its entirety soon.  I have a lot more coming on that front as well, including the announcement of a launch date, so stay tuned.

I mention completing the book because this should leave me with more time and material to post here on DaedTech.  I’ve mostly cross posted from the other blogs I write for of late, but look for an uptick in posts here.  Alongside that change, I’m going to be shuffling some other things around in my life as well, and changing my focus somewhat in the coming months.  I’ll get to all of this later, but for now, suffice it to say that I plan to post more about the suboptimal current state of the corporate entity and what I believe we can do about it.

And, I’ll start that tonight, with a theme that I wanted to address but didn’t fit particularly well in the book itself.  I’m talking about all of the ways that the corporation has come to simulate a sort of parental/teacher hybrid for adults.

Caveats

Before I go too far, I want to say that I’m not intending to serve up a blistering critique of society, per se.  I feel more philosophical and observational about this.  In other words, think less “this is all so stupid and people are sheep” and more “how and why did we get to this place?”

I understand the how, to some degree.  I think, anyway.  Pyramid shaped corporations (the standard corporate structure) have a knack for becoming less than the sum of their parts.  You can get buy with common sense up to a certain level of scale, and then finally you get some weirdo that likes to clip his fingernails next to the coffee machine no matter how much anyone asks him not to.  Then, bam.  You’ve got a sign next to your coffee machine exhorting people not to clip their fingernails, and your whole company looks ridiculous.

I think that organizational childishness tends to scale more than linearly with the average marginal childishness of individuals hired.  The bigger you get, the more your collective adulthood escapes.  Still, though, it’s amazing we don’t blink more often and scratch our head at the state of things.

Read More

By

Collaborating with Outsiders to the Dev Team

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.

Developer news sites, blogs, books, and tutorials tend to speak at length about how developers should collaborate with one another to maximize team effectiveness. The subject of how developers should collaborate with people outside of their team often gets shorter shrift, however.

Personally, I find this to be a shame.  I think it tends to reinforce the stereotype that developers do a poor job of human interaction and need an organizational layer of people to translate between them and normal humans.  I would prefer to live in a world where people didn’t draw distinctions between “the developers” and “the business” because it was simply assumed that software development was part of the business.

For this reason, I’d like to offer some thoughts on how you, as a developer, can most effectively collaborate with non-developers — people outside of your team.  I will offer the caveat that some teams, particularly Scrum teams, are cross functional and thus include non-developers in the team itself.  I understand that, but for the purpose of speaking to the broadest audience, I will presuppose that your team is specialized in the sense that it is made up exclusively of software developers.  Besides, if your team does include other disciplines, it isn’t as if advice on how to collaborate with those folks magically becomes invalid.

Before getting into specifics, I want to mention two universal principles.  The first I will call out only briefly now and not again because it should be common sense and go without saying.  But, in case it doesn’t, treat these colleagues with courtesy and respect.  They are intelligent knowledge workers that simply have a different specialty than you do, and you ought to treat them as such.  If you can’t do it simply as part of being a decent human being, do it because acting like a primadonna is career limiting.  The second principle I’ll mention is that, because these collaborators are intelligent knowledge workers with a different specialty, you should endeavor to learn from them to improve your own work.

Read More

By

Top Heavy Department Growth

I’ve been somewhat remiss in answering reader questions lately.  Largely, I’ve lapsed because I’m choosing to focus on my upcoming book.  Nevertheless, I apologize for the lapse.  I do appreciate all the questions you folks send my way.  I’ll try to compensate today with this post about organizations engaging in top heavy department growth.

I’ll paraphrase this reader question because the specificity of the titles and information involved could make it sensitive if I didn’t take a couple of liberties.

I read your article about architect title over-specialization.  I’m a software developer with senior level experience.

Recently, my company has created “levels” above me.  I used to have only a dev manager above me.  But recently, the organization has brought in both new team leads under the dev manager and architects under a different manager.  Both take precedence over the existing developers.  These people now have authority to tell us what to do and they get to choose what they want to work on, leaving us with the leftovers.

I feel as if i’m being promoted down hill. Can you please advise?

How Companies Expand

If you’re up for it, I’ll offer a good bit of background reading to flesh out the terms.  If not, I’ll furnish minimal definitions here for reference.  A while back, I wrote a post describing the company hierarchy.  That post contains excerpts from my upcoming book, which you can pre-order and read on leanpub.

Here you have an apt illustration of the average company.  At the top, in executive roles, you have opportunistic individuals who define (and violate) the rules and culture of the company.  Then, in the middle, sit the idealists, who guzzle that same kool-aid and ask for more.  Finally, at the bottom toil the pragmatists, who roll their eyes at the company but put up with it for lack of better options.

Significantly, pyramids retain their stability by maintaining their shape.  Thus the most stabilizing growth pattern involves rewarding (over-promoting) loyal pragmatists, and hiring a bunch of grunts beneath them.  If you think of an existing pyramid that needs to get larger, you wouldn’t heap stuff on top.  Instead, you’d build from the bottom.  You’d pull some senior developers, make them architects or team leads to reward them hanging around, and hire a bunch of new grunts to report to them.

Read More