DaedTech

Stories about Software

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
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
11

By

Striking the Standards Balance: Scale Up without the Bureaucracy

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

Editorial Note: I originally wrote this post for the Telerik blog.  You can check out the original here, at their site.  While you’re there, have a look around at their extensive product offering.

In a whitepaper I wrote recently, I talked about two hypothetical organizations.  I used them to offer a study in hyperbolic contrast.

The first had a team of five developers, none of whom used the same development practices. In fact, one of them used a completely different programming language.  They tracked defects using email, and they operated less as a group and more as a collection of ships passing in the night.  If a customer issue arose in the code of a person on vacation, well, then that customer just had to wait.

On the other side of the aisle sat a massive enterprise.  Here, the team not only used the same programming language, but the same everything.  The organization restricted access to the machines so that developers couldn’t install anything of their choosing.  Instead of leaving things to chance, an architectural center of excellence controlled design decisions.  And any deviation from any practice required forms in triplicate.

I used this hyperbole to draw contrast between teams that could benefit from standardization and teams crippled by it.  Predictably, scale plays an important role in the distinction.  To scale an enterprise, one must standardize some operational concerns.  But in doing so, it risks choking the life out of individual innovation.

How can you standardize while minimizing bureaucracy?  Today, I’d like to offer some tips for striking the balance.

Read More

Apr
7

By

The Polyglot’s Dilemma

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

Few things seem as institutional to the programming world as what I call the experience tuple.  A company needs to hire someone to automate something, so, naturally, it asks the software development group to make alphabet soup for dice.com.  “We need someone with (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX) with (React, MSTest, Moq, CSS) as plus.”  Presumably then, polyglot applicants stand a better chance.  But I’d argue that they also face something I’ll call the polyglot’s dilemma.

Hold on to your hats, programmers, because this will get counter-intuitive before it makes sense.  With that in mind… where to start?

Problem Solvers and Problem Transformers

Well, perhaps categorizing hired software developers as problems makes for a good start.  I don’t mean problems in a negative sense, but rather in the same vein as puzzles.  A business hires software developers for some broader purpose.  Maybe they work on internal automation that reduces operating expenses.  Or perhaps they produce software sold as a good or service and add to top line revenue.

In either case, the business implicitly says “I need help increasing our profitability.”  And you show up saying the following.

I have (8, 10, 10, 4, 6, 3, 1, 1, 0) years of (C#, XML, HTML, JS, ASP, MVC, REST, Angular, AJAX).  Now while the rest of you figure out how to make use of me, I’ll be over here sharpening the saw with some code katas.

Whenever I’ve had management responsibility, I’ve subconsciously put people into two buckets.  Problem solvers take a problem I have and make it go away.  Problem transformers take a problem I have and solve it by bringing me the next problem.  (I’m omitting non-performers who don’t solve problems at all as beyond the scope of this post.)

For instance, take the problem of a malfunctioning production server.  A problem solver would go off and come back with a functioning production server, somehow.  A problem transformer would come back, report that the problem was caused by a faulty power supply and ask what I wanted to do about that new problem.

As programmers, we behave as problem transformers.  We present ourselves and our skill sets as problems in need of management solutions.

Read More

Mar
21

By

Don’t Just Flag It — Fix It!

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

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, download a trial of CodeIt.Right.

More years ago than I’d care to admit, I took a software engineering course as part of my graduate CS program.  At the time, I worked a full time job during the day and did remote classes in the evening.  As a result, I disproportionately valued classes with applicability to my job.  And this class offered plenty of that.

We scratched the surface on such diverse topics as agile methodologies, automated testing, cost of code ownership, and more.  But I found myself perhaps most interested by the dive we did into refactoring.  The idea of reworking internal structure of code while preserving inputs and outputs is a surprisingly complex one.

Historical Complexity of Refactoring

At the risk of dating myself, I took this course in the fall of 2006.  While automated refactorings in your IDE now seem commonplace, back then, they were hard.  In fact, the professor of the course considered them to be sufficiently difficult as to steer a group of mine away from a project implementing some.  In the world of 2006, I suspect he had the right of it.  We steered clear.

In 2016, implementing automated refactorings still presents a challenge.  But modern tool and IDE vendors can stand on the shoulders of giants, so to speak.  Back then?  Not so much.

Refactorings present a unique challenge to tool vendors because of the inherent risk.  They can really screw up users’ code.  If a mistake happens, best case scenario is that the resultant code fails to compile because then, at least, it fails fast.  Worse still is semantically and syntactically correct code that somehow behaves improperly.  In this situation, a refactoring — a safe change to code — becomes a modification to the behavior of production code instead.  Ouch.

On top of the risk, the implementation of refactoring anywhere beyond the trivial involves heady concepts such as abstract syntax trees.  In other words, it’s not for lightweights.  So to recap, refactoring is risky and difficult.  And this is the landscape faced by tool authors.

I Don’t Fix — I Just Flag

If you live in the US, you may have seen a commercial that features a funny quip.  If I’m not mistaken, it advertises for some sort of fraud prevention services.  (Pardon any slight inaccuracies, as I recount this as best I can, from memory.)

In the ad, bank robbers hold a bank hostage in a rather cliche, dramatic scene.  Off to the side, a woman stands near a security guard, asking him why he didn’t do anything to stop it.  “I’m not a robbery prevention service — I’m a robbery monitoring service.  Oh, by the way, there’s a robbery.”

It brings a chuckle, but it also brings an underlying point.  In many situations, monitoring alone can prove woefully ineffective, prompting frustration.  As a former manager and current consultant, I generally advise people that they should only point out problems when they have also prepared solution proposals.  It can mean the difference between complaining and solving.

So you can imagine and probably share my frustration at tools that just flag problems and leave it to you to investigate further and fix them.  We feel like the woman standing next to the “robbery monitor,” wondering how useful the service is to us.

Levels of Solution

Going back to the subject of software development, we see this dynamic in a number of places.  The compiler, the IDE, productivity ad-ins, static analysis tools, and linting utilities all offer us warnings to heed.

Often, that’s all we get.  The utility says, “hey, something is wrong here, but you’re going to have to figure out what.”  I tend to think of that as the basic level of service, or level 0, if you will.

The next level, level 1, involves at least offering some form of next action.  It might be as simple as offering a help file, inline reading, or a link to more information.  Anything above “this is a problem.”

Level 2 ups the ante by offering a recommendation for what to do next.  “You have a dependency cycle.  You should fix this by looking at these three components and removing one mutual dependency.”  It goes beyond giving you a next thing to do and gives you the next thing to do.

Level 3 rounds out the field by actually performing the action for you (following a prompt, of course).  “You’ve accidentally hidden a method on the parent class.  Click here to rename or click here to make parent virtual.”  That’s just an example off the top, of course, but it illustrates the interaction paradigm.  “We’ve noticed a problem and you can click here to fix it.”

Fixes in Your Tooling

When evaluating your own tools, look to climb as high up this hierarchy as you can.  Favor tools that identify problems, but offer fixes whenever possible.

There are a number of such tools out there, including CodeIt.Right.  Using tools like this is a pleasure, because it removes the burden of research and implementation from you.  Well, you can always do the research if you want, but at your own leisure.  But it’s much better to do research at your leisure than when you’re trying to accomplish something else.

The other, important concern here is that you find trusted tooling to help you with this sort of thing.  After all, you don’t want something messing with your source code if it might mess up your source code.  But, assuming you can trust it, this provides an invaluable boost to your effectiveness by automatically resolving your problems and by helping you learn.

In the year 2016, we have far more tooling available, with a far better track record, than we did in 2006.  Leverage it whenever possible so that you can focus on solving the pressing problems of your day to day work.

« Older Posts
Newer Posts »