DaedTech

Stories about Software

Oct
6

By

Undercover Testability Killers

Category: Language Agnostic Tags: , |

Editorial Notes: I originally wrote this post for the Infragistics blog.  You can check out the original here, at their site.  While you’re there, take a look around at the other posts by their contributing authors.

If you were to take a poll of software development shops and ask whether or not they unit tested, you’d get varied responses.  Some would heartily say that they are, and some would sheepishly say that they totally mean to get around to that next year and that they’ve totally been looking into it.  In the middle, you’d get a whole lot of responses that amounted to, “it’s complicated.”

In my travels as a consultant, I witness the reason for this firsthand.  The adoption rate of automated testing has increased dramatically in the last decade, and that increased adoption means that a lot of shops are taking the plunge.  And naturally, this means that a lot of shops with a lot of legacy code and awkward constructs in their codebases are taking the plunge, which leads to interesting, complicated results.

Complicated

It’s Complicated

“It’s complicated” generally involves variants of “we tried but it wasn’t for us” and “we do it when we can, but the switch hasn’t flipped yet.”  And, at the root of all of these variants lies a truth that’s difficult to own up to when talking about your group – “we’re having trouble getting any good at this.”

If this describes you or folks you know, take heart, though.  The “Intro to TDD” and “NUnit 101” guides make it look really, really easy.  But those sources of learning usually show you how to write unit tests for things like “in-memory calculator,” intending to simplify the domain and code so that you understand the mechanics of a unit test.  But, in doing this, they paint a deceptive picture of how easy covering your code with tests should be.

If you’ve been writing code for years with nary a thought to testing at the unit level, it’s likely that familiar, comfortable coding practices of yours are proving to be false friends.  In other words, your codebase is probably littered with things that are actively making your life extremely difficult as you try to adopt automated testing.  What follows are some of the most common ones that I see.

Read More

Oct
5

By

Securing Yourself a Better Title

Category: You Asked For It Tags: , | 9 Comments

Tonight marked the vice-presidential debate and the start of the baseball playoffs.  With two spectator sports on television, I thought I’d draw some inspiration and answer a reader question about office politics.  This question came to me from a reader whose problem tracks back (in my opinion) to need for a better job title.  And it came in lengthy format, checking in about 1,100 words!

For the sake of both poster anonymity and brevity, I will summarize with as little information loss as possible.  My summary is as follows.

I finished a CS degree and took an entry level position.  From there, I took a job that involved writing code — automation around Selenium to be used by a QA group for testing.  I believe this mimics the role of Google’s “Software Engineer in Test.”  That said, the conferred upon me the title of “QA Engineer.”

For two years, I enjoyed the development work in this role and made inroads toward an advancement.  Before that happened, however, my company shuffled departments, and I found myself in a new part of the company, under a new boss.  This new boss only saw me for my title, rendering my progress moot.

I approached him about my situation and he agreed to put me on a more classic development team, but on a “probationary” basis.  He said that he’d consider a formal change in six months if I could work on defects and get my fix rate up to a certain number per week.  Six months later, at a review, he said that I had made definite progress, but that my rate of X per week was just not QUITE high enough and that we could talk again next year at performance review time.

What are my options?  What should I do next?  I feel that I’ve now fallen behind people of a similar, salary-wise, and I feel stuck in a rut.

GlumGuy

Title Matters

Let me start by offering a quick bit of context.  Recruiters and people offering you jobs with bad titles will tell you that titles don’t matter.  Don’t listen to recruiters and people offering you bad titles because titles do matter.

They matter because a job title counts as what I’ll call passive bargaining material.  When you navigate the waters of your career, you will have negotiation points where you look for more salary or benefits or whatever.  The actual negotiating constitutes the active component of this dance, and that matters.  But so does the passive portion: your previous/current title, salary, benefits, etc.

Don’t believe me?  If you’re a developer, cold-apply to a bunch of dev manager or director gigs.  No responses?  Try adding a fictitious 5 year stint as “Director of Software Engineering” to the top and try again.  Bet you get at least a few calls.

Read More

Oct
2

By

Habits that Help Code Quality

Category: Language Agnostic Tags: |

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  If you like posts about static analysis, code quality, and the like, check out the rest of the blog.

When I’m called in to do a strategic assessment of a codebase, it’s never the result of everything being awesome.  That is, no one calls me up and says, “we’re ahead of schedule, under budget, and knocking it out of the park, so can you come in and tell us what you think of our code?”  Rather, I get calls when something isn’t going according to plan and the business people involved want to get some insight into what underlying causes there are in the code and in the team’s approach.

When the business gets involved this way, there is invariably a fiscal operational concern, either overtly or lurking just beneath the surface.  I’ll roll this up to the general consideration of “total cost of ownership” for the codebase.  The business is thus asking, “why are things proving more expensive than we thought?”

ProfitsTrendingUp

Typically, I come in, size up the situation, quantify it objectively, and then use analogies and examples to make clear what’s happening.  After I do this, pretty much without exception, the decision-makers to whom I’m speaking want to know what small things they can do, internally, to course correct.  This makes sense when you think about it.  If your doctor told you that your health outlook wasn’t great, you’d cross your fingers and say, “but I can fix it by changing my diet and exercise a little, right?”  You wouldn’t throw yourself on the table and say, “cut me open and make sure whatever you do is expensive!”

I am thus frequently asked, by both developers and by management, “what are the little things we can do to improve and maintain code quality.”  As such, this seems like excellent fodder for a blog post.  Here are my tips, based on years of observation of what correlates with healthy codebases and what correlates with distressed ones.

Read More

Sep
29

By

What Does Code Quality Really Mean?

Category: The Life of a Programmer Tags: , | 5 Comments

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  While you’re there, have a look around and check out Collaborator, the code review tool.

Let’s say that you wanted a definitive explanation, once and for all, as to what constitutes code quality.  You might take to google and type “definition of code quality,” which would yield a post from this very blog as well as a sampling of Q&A sites.  For the purposes of this post, however, I’d like to examine the entry that occurs here, at programmers’ stack exchange.  I think it may be the perfect microcosm for this discussion.

The Q&A Site Consensus

The question is simple enough: “what does it mean to write good code?”  The answer receiving the most votes is one in which the respondent draws a parallel to top-notch pool players, who are so good that they set up their next shot as an easy one, even while making the current shot. High-quality code “looks like it was easy and straightforward to do.”  This is a classic example of “I can’t define it, but I know it when I see it.”  You can recognize code quality because it “looks easy.”

pool-player

Next up in vote total was a response that cited a popular, somewhat crass cartoon.  The gist of it is that code quality is inversely proportional to the number of perturbed utterances per minute on the part of people reading the code.  High quality code is code that triggers this response infrequently, whereas low quality code triggers this response vehemently and regularly.  Like the answer preceding it, this is not a definition but a recognition heuristic.  But with this response, the respondent clarifies that such a definition may actually be impossible, and heuristics are the best approximation.

From there, the answers get more specific and acquire fewer votes each.  One respondent offers “how fast can you understand the code” as the defining criteria for high quality code.  It is easy to imagine push-back by someone pointing out that “while(true) { }” is trivial to understand, but the resultant application that simply hangs is probably not the product of high quality code.  For the most part, the rest of the answers list properties of good code in an attempt to provide the requested definition.  “Good code is bug-free, reusable, well-documented, easy to change, etc.”  None of these garnered many votes, but each did receive a few.

So what was the verdict?  There was no accepted answer and the moderators closed the question as “not constructive.”  The reason cited was, “this question will likely solicit debate, arguments, polling, or extended discussion,” thus rendering the question not a fit for Stack Exchange’s paradigm of being a Q&A site with discrete and concrete answers.  This is not an indictment of the question, per se, but rather a determination that it’s inherently subjective.

Read More

Sep
28

By

Software Architect as a Developer Pension Plan

Category: Free Agent Developers Tags: , , | 16 Comments

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

« Older Posts
Newer Posts »