DaedTech

Stories about Software

Oct
23

By

Targeted Code Reviews in Regulated Industries

Category: The Life of a Programmer Tags: |

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, check out the work of the other authors writing for them as well.

For a lot of people out there developing software, life is pretty simple.  I say this not because there’s anything simple about software development, but because life around the practice of software development is simple.  You come in around 9, spend the day doing what the software needs to have done to it, and you go home at 5.  Maybe every now and then you stay late some days to make a push.

As organizations get bigger and more specialized, however, the outlook starts to change.  Growth brings larger and larger headcount, which, in turn, means more communication channels and general, bureaucratic overhead.  Growth also brings more outsider scrutiny and general public interest, particularly as companies go public and make headlines.  Such organizations start to become regulated.

Clipboard

Simply put, a regulated organization is one in which the government takes an interest.  Legislation about how the organization must behave is created, enacted, and enforced, the latter often coming in the form of check-ups, inspections, or audits.  Large companies may find themselves regulated in ad hoc fashion, or it may happen due to their size and public influence.  Other companies are regulated at any size, simply by virtue of their industry.  This latter designation applies to the finance, energy, healthcare, and defense industries, to name a few.

The Productivity Impact of Regulation

However your company comes to be regulated, the impact on you, as a software developer, is noticeable.  You have to do stuff with which your peers at other organizations needn’t bother.  You need to follow certain protocols for database access or document your code in certain ways.  Often times, and at larger organizations, this takes on a “death by a thousand cuts” status in your life, and it starts to feel as though you do a lot more box-checking than software development.

This, in spite of the importance of complying with this regulations, is an untenable state of affairs for a group.  To put a point on it with hyperbole, one surefire way to have your software comply with all regulations is not to write any software.  And, while that’s clearly never the actual mission of your company, it can sometimes feel that way as regulation compliance starts to swallow your time.

Read More

Oct
16

By

Reviewing Strangers’ Code on Github

Category: The Life of a Programmer Tags: , | 2 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, check out some of the pieces by their other authors.

I make part of my living these days as an IT management consultant, and in this capacity, I’ve developed an interesting niche: evaluation of codebases.  Specifically, an organization’t management will bring me in to spend a week or two looking through a codebase, sizing it up, and making recommendations for what to do with it going forward (e.g. “stay the course, rework the architecture, targeted training, scrap it, etc.”)

As you might imagine, this part of my practice leads me to looking at and quickly grokking a lot of unfamiliar code.  Every few weeks, I’m squinting at strange classes, running static analysis tools, and making lists of assumptions and questions to ask the development team.  And I’ve found that this practice has benefits to me beyond helping me earn my living.  I’d argue that it makes me a better programmer.

Consider the opposite situation — one that describes an enormous cross section of industry developers.  They come in to work each day and deal with the same codebase.  This continues day in and day out for weeks, months, or even years.

This year, my wife and I are hoping to make a visit to the Galapagos Islands, which are noteworthy for the uniqueness of the wildlife there.  The animals living there have been isolated from the wider world of fauna for millions of years, and the result is that they’ve developed unique and unusual characteristics that cannot be found anywhere else.  This is what tends to happen to codebases in shops where the majority of developers work in relative isolation.  A bubble forms, and practices drift toward the unusual.

bird

For an individual, this isolation tends to put a damper on skill acquisition and can even be career limiting.  It’s the polar opposite of the situation in which I find myself — constantly immersed in unfamiliar code.  So how can you remedy the isolation if your professional life shows you the same code in day in and day out?  (Without drastic career moves, that is).  Well, the dead simplest thing I can think of is to seek out and review other people’s code.  And to do that, there’s no better place to go than Github.

Here’s what you can do.  Every few weeks or so, poke around idly on Github, searching for random codebases in your language of choice.  Big or small, popular or niche, active or forgotten — it really doesn’t matter much.  They just need to be different and new.

Once you’ve found one (and just about any one will do), clone it and get the code locally on your machine.  Open it up in your IDE/editor/environment of choice, and start looking around.  If you start to perform this exercise with some regularity, here are some benefits that you can expect, in my experience.

Read More

Oct
14

By

What to do when Your Colleague Creates Spaghetti Code

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

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, take a look around and give NDepend a try.

I write for a number of different outfits and earn my living consulting around software and IT.  Because of the intersection of these three concerns — writing, offering advice professionally, and software — I field a lot of requests for advice on how to do the right technical thing without everyone around you shooting holes in it.  Consider an example.

“How can we get started with unit testing?”

Considered as a technical question alone, this invites a fairly obtuse response.  “First, write a unit test.  Second, run the unit test.”  Obviously, that’s not really what anyone is asking when they ask this question.

Instead, they want to know something orders of magnitude more complex.  “How can we overcome years of inertia, a nasty legacy codebase, Bill, who has been around for 40 years and hates everything new, and the fact that management doesn’t want to pay us to write ‘extra’ code… and then start unit testing?”  Oh, yeah, that.  Well, that’s complicated.

I frequently hear such apparently-innocuous-but-actually-complex questions about code quality.  “This idiot on my team is writing mountains of the most unmaintainable garbage imaginable — what should I do?”

spaghetti

Usually, this sort of question comes to me from people at client sites.  And, accordingly, I have to balance the answer that makes the most sense for the individual with the one that keeps the client’s best interests in mind.  The client pays my bill, and I have a charter to lower the cost of ownership and development of their code.

But when I’m in writer mode, and only the asker’s interests matter, I’l give a subtly different answer.  Today, I’d like to offer advice on what you should do in this situation.

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
25

By

Defining Developer Collaboration

Category: The Life of a Programmer Tags: , | 1 Comment

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

« Older Posts
Newer Posts »