DaedTech

Stories about Software

Jun
30

By

Does Github Enhance the Need for Code Review?

Category: The Life of a Programmer Tags: | 4 Comments

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Take a look around while you’re there and check out their products and other posts.

In 1999, a man named Eric S. Raymond published a book called, “The Cathedral and the Bazaar.”  In this book, he introduced a pithy phrase, “given enough eyeballs, all bugs are shallow,” that he named Linus’ Law after Linux creator Linus Torvalds.  Raymond was calling out a dichotomy that existed in the software world of the 1990s, and he was throwing his lot in with the heavy underdog at the time, the bazaar.  That dichotomy still exists today, after a fashion, but Raymond and his bazaar are no longer underdogs.  They are decisive victors, thanks in no small part to a website called Github.  And the only people still duking it out in this battle are those who have yet to look up and realize that it’s over and they have lost.

Cathedral

Cathedrals and Bazaars in the 1990s

Raymond’s cathedral was heavily-planned, jealously-guarded, proprietary software.  In the 1990s, this was virtually synonymous with Microsoft, but certainly included large software companies, relational database vendors, shrink-wrap software makers, and just about anyone doing it for profit.  There was a centrally created architecture and it was executed in top down fashion by all of the developer cogs in the for-profit machine.  The software would ship maybe every year, and in the run up to that time, the comparably few developers with access to the source code would hunt down as many bugs as they could ahead of shipping.  Users would then find the rest, and they’d wait until the next yearly release to see fixes (or, maybe, they’d see a patch after some months).  The name, “cathedral” refers to the irreducible nature of a medieval cathedral — everything is intricately crafted in all or nothing fashion before the public is admitted.

The bazaar, on the other hand, was open source software, represented largely at the time by Linux and Apache.  The source code for these projects was, obviously, free to all to look at and modify over the nascent internet.  Releases there happened frequently and the work was crowd-sourced as much as possible.  When bugs were found following a release, the users could and did hunt them down, fix them, and push the fix back to the main branch of the source code very quickly.  The cycle time between discovery and correction was much, much smaller.  This model was called the bazaar because of the comparably bustling, freewheeling nature of the cooperation; it resembled a loud, spontaneously organized marketplace that was surprisingly effective for regulating commerce.

Read More

Jun
29

By

How Do I Find Good Recruiters?

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

I’ve fallen off my cadence with answering reader questions of late, so I’d like to correct that today.  The question in question is a fairly straight forward one about how to find good recruiters.  This one is actually lifted from a comment some time back that I thought would be more conducive to a post than a comment response.

I would like to ask you how you get to “good” recruiters? My experience with recruiters has been rather negative and I’m wondering if I’m doing something wrong here.

First of all, it’s had to imagine that you’re doing anything wrong.  From the perspective of the job seeker, this is not a difficult transaction.  It’s a lot more likely that the problem lies with the recruiting field in general.

What Makes Them Good?

I’ve had a lot of experience with recruiters, both on the hiring and applicant ends — enough to know well how the game works.  I’ve explained this before, about a year ago.  Short form version is that the typical recruiting firm will take nothing from the applicant, but will take 15 – 20 percent of the first year’s salary from the company that makes the hire.  This cut will be refundable if the applicant leaves within something like six months.  The recruiter’s game is thus to make a match and hope it sticks for 6 months.

Amway

Recruiters’ customers are thus hiring companies, and not you.  It’s like Facebook — you’re the product, not the customer.  The majority of recruiters are in the business of selling humans (that happens to be developers) to companies.  The good recruiters are in the business of selling a match to both the human and the company, since this is the best way to build reputation and avoid the six month refund blues.

But most recruiters are not good — they’re shooting for quantity over quality by treating you as the product.

Read More

Jun
26

By

Learning a Healthy Fear of Legacy Code

Category: Language Agnostic Tags: |

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re at it, have a look around at some of the other authors posting there as well.

The life of a developer would be pretty much nothing but rainbows and unicorns if all we did was add new code to code bases. Imagine a world without maintenance programming, debugging, and scratching your head while squinting at confusing, existing code. It’d be pretty nice, right?

Unicorn with Rainbow

Sadly, we don’t live in that world. The result is that most of our efforts in software development involve a blend of new and old code. We write some new code, stuff it into some existing code, and then try to figure out how the two things will behave together in production. Consequently, both writing and reviewing code necessarily involve a kind of constant, subconscious risk management. “Hmm… should we really touch this code?”

There’s rarely a set of explicit heuristics that guide this decision; it tends to be a matter of feel. It’d be nice if there were a way to be a bit more deliberate about it.

Understanding Legacy Code

“Legacy code” is a rather nebulous term.  Even the wikipedia entry offers multiple, possible meanings.

  • Code that relates to a no-longer supported hardware or software dependency.
  • Code inherited from someone else.
  • Code that’s part of an older version of the software.
  • Code that isn’t covered by automated unit tests.

When I think about what pops into my head when someone says, “legacy code,” none of these things would surprise me.  I could imagine any or all of them being true.  But for me, legacy code really translates to, “code you’re afraid to touch.”

Read More

Jun
23

By

Code Review and How Enterprises Can Miss The Point

Category: Language Agnostic Tags: | 4 Comments

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.  Check out my posts and some of the others and take a look at their products as well while you’re there.

If you work for a smallish company, as part of a modestly sized software development group, the path to a code review policy is likely a short, direct one.  It could be as simple as a respected team member or the manager saying, “hey, let’s start doing code review.”  But whatever the impetus, the participants will tie the process closely enough to the desired outcomes from it to adapt it as needed.

The Capital E Enterprise

At the enterprise level, the calculus changes considerably. And when I say the enterprise, I mean The Enterprise – a size and scope mammoth enough to demand capitalization, even when the rules of grammar do not. These are companies so big that those who work at and have worked at them will assure you that there is simply nothing out there that’s comparable. There are, they will tell you, an entirely different set of rules that apply. And they’re more or less right.

The Enterprise loves structure and hierarchy, usually of the command and control variety. The scale is so immense that the only structure up to the task is a pyramid reminiscent of a military chain of command. The organization lumbers along like a battleship, powerful, majestic, and requiring incredible teamwork, cooperation, and precision to change direction in any way.

GoofyOrgChart

In this environment, code review tends to make its way to development team in a very different way and for very different reasons. Of course, even in a massively homogenized environment, one size does not fit all for the development teams. But the cog in a larger machine dynamic makes the following sort of scenario much more likely.

Read More

Jun
22

By

With Code Metrics, Trends are King

Category: Reasoning About Code Tags: , | 13 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  Head over there to check out the original.  NDepend is a tool that’s absolutely essential to my IT management consulting practice, and it’s a good find for any developer and aspiring architects in particular.  Give it a look.

Here’s a scene that’s familiar to any software developer.  You sit down to work with the source code of a new team or project for the first time, pull the code from source control, build it, and then notice that there are literally thousands of compiler warnings.  You shudder a little and ask someone on the team about it, and he gives a shrug that is equal parts guilty and “whatcha gonna do?”  You shake your head and vow to get the warning situation under control.

Fumigation

If you’re not a software developer, what’s going on here isn’t terribly hard to understand.  The compiler is the thing that turns source code into a program, and the compiler warning is the compiler’s way of saying, “you’ve done something icky here, but not icky enough to be a show-stopping error.”  If the team’s code has thousands of compiler warnings, there’s a strong likelihood that all is not well with the code base.  But getting that figure down to zero warnings is going to be a serious effort.

As I’ve mentioned before on this blog, I consult on different kinds of software projects, many of which are legacy rescue efforts.  So sitting down to a new (to me) code base and seeing thousands of warnings is commonplace for me.  When I point the runaway warnings out to the team, the observation is generally met with apathetic resignation, and when I point it out to management, the observation is generally met with some degree of shock.  “Well, let’s get it fixed, and why is it like this?!”  (Usually, they’re not shocked by the idea that there are warts — they know that based on the software’s performance and defect counts — but by the idea that such a concrete, easily metric exists and is being ignored.)

 

Read More

« Older Posts
Newer Posts »