DaedTech

Stories about Software

Apr
20

By

Static Analysis for the Build Machine?

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.  While you’re over there, download a trial of NDepend if you want to see some quantification of the tech debt in your codebase.

I remember my earliest experiences with static analysis.  Probably a decade ago, I started to read about it during grad school and to poke around with it at work.  Immediately, I knew I had discovered a powerful advantage for programmers.  These tools automated knowledge.

While I felt happy to share the knowledge with coworkers, their lack of interest didn’t disappoint me.  After all, it felt as though I had some sort of trade secret.  If those around me chose not to take advantage, I would shine by comparison.  (I have since, I’d like to think, matured a bit.)  Static analysis became my private competitive advantage — Sabermetrics for programmers.

So as you can imagine, running it on the build machine would not have occurred to me.  And that assumes a sophisticated enough setup that doing so made sense (not really the case back then).  Static analysis was my ace in the hole for writing good code — a personal choice and technique.

Fast forward a decade.  I have now grown up, worked with many more teams, and played many more roles.  And, of course, the technological landscape has changed.  All of that combined to cause a complete reversal of my opinion.  Static analysis and its advantages matter far too much not to use it on the build machine.  Today, I’d like to expand on that a bit.

What Does It Mean to Have Static Analysis on the Build Machine?

First point of expansion should be to mention what this means.  In the general sense, this means that the machine responsible for assembling your code into something deployable executes static analysis on said code.  Back when I first discovered static analysis, this would have meant pulling the code from source on that machine, running the analysis and building it.  These days, hopefully your build involves more automation than this.

To get a bit more detailed, a commit may trigger your build machine to kick off a build.  That could just mean compiling your code and packing it into a deployable format.  But shops commonly do other things, such as execute automated unit tests and check on code coverage.  And you can add static analysis to the mix.

You can certainly get creative with how you do this.  But two common (and not mutually exclusive) approaches include having the build generate a code health report and failing the build on egregious violations.

Read More

Apr
18

By

Alternatives to Lines of Code

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

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 — see if your code lies in the Zone of Pain.

It amazes me that, in 2016, I still hear the occasional story of some software team manager measuring developer productivity by committed lines of code (LOC) per day.  In fact, this reminds me of hearing about measles outbreaks.  That this still takes place shocks and creates an intense sense of anachronism.

I don’t have an original source, but Bill Gates is reputed to have offered pithy insight on this topic.  “Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”  This cuts right to the point that “more and faster” does not equal “fit for purpose.”  You can write an awful lot of code without any of it proving useful.

Before heading too far down the management criticism rabbit hole, let’s pull back a bit.  Let’s take a look at why LOC represents such an attractive nuisance for management.

For many managers, years have passed since their days of slinging code (if those days ever existed in the first place).  So this puts them in the unenviable position of managing something relatively opaque to them.  And opacity runs afoul of the standard management playbook, wherein they take responsibility for evaluating performances, forecasting, and establishing metric-based incentives.

The Attraction of Lines of Code

Let’s consider a study in contrasts.  Imagine that you took a job managing a team of ditch diggers.  Each day you could stand there with your clipboard, evaluating visible progress and performance.  The diggers that moved the most dirt per hour would represent your superstars, and the ones that tired easily and took many breaks would represent the laggards.  You could forecast milestones by observing yards dug per day and then extrapolating that over the course of days, weeks, and months.  Your reports up to your superiors practically write themselves.

But now let’s change the game a bit.  Imagine that all ditches were dug purely underground and that you had to remain on the surface at all times.  Suddenly accounts of progress, metrics, and performance all come indirectly.  You need to rely on anecdotes from your team about one another to understand performance.  And you only know whether or not you’ve hit a milestone on the day that water either starts draining or stays where it is.

If you found yourself in this position suddenly, wouldn’t you cling to any semblance of measurability as if it were a life preserver?  Even if you knew it was reductionist, wouldn’t you cling?  Even if you knew it might mislead you?  Such is the plight of the dev manager.

In their world of opacity, lines of code represents something concrete and tangible.  It offers the promise of making their job substantially more approachable.  And so in order to take it away, we need to offer them something else instead.

Read More

Apr
16

By

Eliminating the Job Interview via Partnership

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

If you follow this blog with any regularity, you probably know my take on the job interview.  One of my more popular posts asserts that hiring, as we know it, isn’t worth fixing.  And, my book, Developer Hegemony, contains an excoriating treatment of job interviews.  The practice started as a silly whim about 100 years ago, and we’ve just kept doing it, uncritically, ever since.  I’m going to talk today about partnership, and how I think we can leverage it to help.

But let me set the scene a bit, first.  In Developer Hegemony, I talk in more detail about the world without job interviews.  On the blog, however, I’ve just advised developers to interview with companies that minimize the stupidity of the process.  On the company side, the only advice I’ve offered is to picture a world where you weren’t allowed to interview.  Using this creative constraint, come up with alternatives.

Because of this less than detailed treatment, I’ve received reader questions like the following.  And, understandably so.

I love these articles, but I wish you would write one about what I should be doing to make good hires, instead of reinforcing how bad all the possible options I can think of would be 😉

So I’ve decided to address this.  In today’s post, I’ll offer an idea for an alternative.  I may turn this into a series, with different ideas, but I don’t want to get ahead of myself.

Caveat Emptor

First, a quick disclaimer.  What you’re about to read contains absolutely zero long-contemplated, research-backed academic work.  I haven’t even asked anyone for an opinion on this.

Instead, you can think of this more as something I dreamed up in the shower a few weeks ago.  Since then, I’ve idly contemplated it while waiting to board a plane or going for a walk in nice weather.  In this post, I will actually flesh it out in a bit more detail for my own clarification.

I won’t belabor the point further, but I do want you to understand that holes will exist.  I’m not writing this post to give you a ready-made playbook, but to give you the seed of an idea that you might incorporate as you make hires.  And, plus, it feels good to write something optimistic instead of frustrated and cynical every now and then.

Read More

Apr
14

By

Habits that Pay Off for Programmers

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

Editorial Note: I originally wrote this post for the LogEntries blog.

I would like to clarify something immediately with this post.  Its title does not contain the number 7, nor does it talk about effectiveness.  That was intentional.  I have no interest in trying to piggy-back on Stephen Covey’s book title to earn clicks, which would make this post a dime a dozen.

In fact, a google search of “good habits for programmers” yields just such an appropriation, and it also yields exactly the sorts of articles and posts that you might expect.  They have some number and they talk about what makes programmers good at programming.

But I’d like to focus on a slightly different angle today.  Rather than talk about what makes people better at programming, I’d like to talk about what makes programmers more marketable.  When I say, “habits that pay off,” I mean it literally.

Don’t get me wrong.  Becoming better at programming will certainly correlate with making more money as a programmer.  But this improvement can eventually suffer from diminishing marginal returns.  I’m talking today about practices that will yield the most bang for the buck when it comes time to ask for a raise or seek a new gig.

Read More

Apr
13

By

Elements of Helpful Code Documentation

Category: Language Agnostic Tags: , , |

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, check out GhostDoc, which can automatically generate help files for you.

If you spend enough years writing software, sooner or later, your chosen vocation will force you into reverse engineering.  Some weird API method with an inscrutable name will stymie you.  And you’ll have to plug in random inputs and examine the outputs to figure out what it does.

Clearly, this wastes your time.  Even if you enjoy the detective work, you can’t argue that an employer or client would view this as efficient.  Library and API code should not require you to launch a mystery investigation to determine what it does.

Instead, such code should come with appropriate documentation.  This documentation should move your focus from wondering what the code does to contemplating how best to leverage it.  It should make your life easier.

But what constitutes appropriate documentation?  What particular characteristics does it have?  In this post, I’d like to lay out some elements of helpful code documentation. Read More

« Older Posts
Newer Posts »