DaedTech

Stories about Software

Nov
17

By

Should You Review Requirements and Design Documents?

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, have a look around at posts and knowledge from other authors.

I remember working in a shop that dealt with medical devices some years back.  I can’t recall whether it was the surrounding regulatory requirements or something about the culture at this place, but there was a rule in place that required peer review of everything.

Naturally, this meant that all code was reviewed, but it went beyond that and extended to any sort of artifact produced by the IT organization.  And, since this was a waterfall shop, that meant review (and audit-trails of approval) of the output of the requirements phase and the design phase, which meant requirements and design documents, respectively.  I can thus recall protracted meetings where we sat and soberly reviewed dusty documents that made proclamations about what “the system” shall and shan’t do.  We also reviewed elaborate sequence, flow, hierarchy, and state design artifacts that were probably obsolete before we even reviewed them.

If I make this activity sound underwhelming in its value, that’s because I routinely felt underwhelmed by its value.  It was a classic case of process over common sense, of ceremony over pragmatism.  Everyone’s attention wandered, knowing that all bets would be off once the development started.  Sign-offs were a formality — half-hearted and cursory.

But is it worth throwing the baby out with the bathwater?  Should the fact that waterfall shops waste time on and around these documents stop you from producing them and subsequently reviewing them?  Is it worth reviewing requirements and design documents?

LotsLeftToDo

Read More

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
9

By

Code Review Beyond Meeting Rooms and Projectors

Category: Language Agnostic 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 over there, have a look at their Collaborator offering.

It must have been a decade ago.  I was sitting in a spaciously appointed conference room around a large, round table, surrounded by fellow software developers from my company.  Coffee and bright lights notwithstanding, we were all struggling to varying degree to keep alert.

The reason for our struggle was that we were spending the day doing a marathon code review, and we were barely halfway through the morning.  A representative of the team that had written the code was on hand, walking us through it, showing the code against a pull down screen with a projector.  We were being treated to file after file after file, in alphabetical order, in a text editor.

There were hours of this yet to go.  And yet, it was an unavoidable matter of due diligence.  In spite of our wandering attention spans, we believed this, as did our management.  Our company had contracted with a custom software vendor to write an application that our company would take over and maintain.  This firm had scurried off for 9 months or so, and they were now presenting “phase 1” to us.  This was our chance to raise concerns and provide input.  Theoretically, anyway.

CarryingTooMuch

As you can imagine, this was not an especially effective way to spend a day (or several, as it would turn out).  We technically saw all of the code that was being delivered, but it wasn’t as though this activity produced a lot of meaningful output.  There were some obvious reasons for this, such as the enormous batch of reviewing 9 months of code and the marathon, all-in nature of the session.  But there were also some issues related to tooling and process that were pretty limiting compared to what we have now.

10 years have elapsed since this yawn-inducing series of days I spent in review.  And, while you’re still going to be in trouble if you try meaningfully to review 9 months of a team’s code in a few days, tools and workflows have emerged in the interceding years that make code review much easier.  You should be taking advantage of them.

Read More

Sep
15

By

Why Automate Code Reviews?

Category: Language Agnostic Tags: , | 10 Comments

Editorial Note:  I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  This is a new partner for whom I’ve started writing recently.  They offer automated code review and documentation tooling in the .NET space, so if that interests you, I encourage you to take a look.

In the world of programming, 15 years or so of professional experience makes me a grizzled veteran.  That certainly does not hold for the work force in general, but youth dominates our industry via the absolute explosion of demand for new programmers.  Given the tendency of developers to move around between projects and companies, 15 years have shown me a great deal of variety.

Lifer

Perhaps nothing has exemplified this variety more than the code review.  I’ve participated in code reviews that were grueling, depressing marathons.  On the flip side, I’ve participated in ones where I learned things that would prove valuable to my career.  And I’ve seen just about everything in between.

Our industry has come to accept that peer review works.  In the book Code Complete, author Steve McConnell cites it, in some circumstance, as the single most effective technique for avoiding defects.  And, of course, it helps with knowledge transfer and learning.  But here’s the rub — implemented poorly, it can also do a lot of harm.

Today, I’d like to make the case for the automated code review.  Let me be clear.  I do not view this as a replacement for any manual code review, but as a supplement and another tool in the tool chest.  But I will say that automated code review carries less risk than its manual counterpart of having negative consequences.

Read More

« Older Posts
Newer Posts »