DaedTech

Stories about Software

Apr
10

By

Visualizing Your (Real) Architecture

Category: Reasoning About Code Tags: , | 6 Comments

Editorial note: I originally wrote this post for the NDepend blog.  Go check out the original at the NDepend site.  Take a look around at the other posts while you’re there as well — there’s a lot of good stuff to be had.

Diagrams of software architecture have a certain aesthetic appeal to them.  They usually consist of grayscale or muted pastel colors and nice, soft shapes with rounded edges.  The architects that make them assemble them into pleasing patterns and flowing structures such that they often resemble 7-layer cakes, pinwheels, or slalom courses.  With circles and ovals arranged neatly inside of rectangles connected by arrows, there is a certain, orderly beauty.  If you’re lucky, there will even be some fluffy clouds.

If you want to see an example, here’s one that has it all.  It’s even got a service bus.  Clearly, the battle for quality was over long before the first shots were ever fired.  After the initial conception of this thing, the mundane details of bringing the architecture to life would likely have been a simple matter of digital paint by numbers.  Implement an interface here, inherit from a framework class there, and Presto!  Instant operational beauty that functions as smoothly on servers as it does in the executive readout power point.

At least, that’s the plan.

Read More

Feb
11

By

Mistakes Dev Managers Make

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

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at the site.  If you like this post, head on over, and check out more at the site.

Managing a team of software developers is a tall order. This is doubly true when the line management includes both org chart duties (career development, HR administrivia, etc) and responsibility for the team’s performance when it comes to shipping. In this case, you’re being asked to understand their day to day performance well enough to evaluate their performance and drive improvement, in spite of the fact that what they do is utterly opaque to you. It’s like being asked to simultaneously coach a team and referee the game for a sport whose rules you don’t know. As I said, a tall order.

I’ll grant that, if you’re a manager, you may have been technical at some point, perhaps even recently. Or maybe not, but you’ve been around it long enough to pick up a lot of concepts, at least in the abstract. But in neither case, if you were asked what, exactly, Alice coded up yesterday, would you be able to answer. Whether it’s due to total lack of experience, being “rusty” from not having programmed in a number of years, or simply being unable to keep up with what 8 other people are doing, their work is opaque to you.

As with coaching/refereeing the game that you don’t understand, you can pick up on their body language and gestures. If all members of the team appear disgusted with one of their mates, that one probably did something bad. You’re not totally without context clues and levers to pull, but it wouldn’t be hard at all for them to put one over on you, if they were so inclined. You’re navigating a pretty tough obstacle course.

And so it becomes pretty easy to make mistakes. It’s also pretty understandable, given the lay of the land. I’ll take you through a few of the more common ones that I tend to see, and offer some thoughts on what you can do instead.

Micromanagement

The opacity of the development team’s labor creates a situation in which it’s easy to feel as though you don’t have control.  And a perfectly natural impulse in such a situation is to overcompensate and try to exert as much control as possible.  The overwhelming majority of folks that micromanage don’t think to themselves, “I want to be an insufferable control freak,” but rather something along the lines of, “I just need to get really involved for now while we’re facing this deadline, and then I’ll back off when things settle down.”

GrabbingTheWheel

Read More

Feb
7

By

Hidden Costs in Your Software

Category: Language Agnostic Tags: | 1 Comment

Editorial Note: I originally wrote this post for the NDepend blog.  Go check it out over there, if you’re so inclined.  You’ll like the posts over there if you like static analysis and philosophical discussions of software design and architecture.  Also, this week will probably consist mainly of cross posts as my wife and I are going to spend a few days in a hotel in New Orleans, taking in the spectacle of Mardi Gras.

One of the things I remember most vividly from my CIO days was the RFP process for handling spikes in demands on my group’s time.  In case you haven’t participated in this on either side, the dance involves writing up a brief project description, sending it over to a handful of software consulting firms, and getting back tentative project proposals.  I’d pick one, and work would begin.

There were a lot more documents and legalese involved, but the gist, writ small, might be something like, “we need an application that will run in our data center, take information about customers out of our proprietary database, and put it back into our CRM as notes, depending on a series of business rules.”  The response, in proposal form, would essentially be, “we’ll do that, and we think it’ll cost you about $30,000.”

This is what most people think of as the cost of a software project.  Perhaps it’s not a little, 5-figure line of business utility.  Perhaps it’s a $300,000 web or mobile application.  Perhaps it’s even a $30,000,000 enterprise workflow overhaul.  Whatever the case may be, there’s a tendency to think of software in terms of the cost of the labor necessary to write it.  The consulting firms would always base their proposals and estimates on a “blended rate” of the hourly cost of the labor.  Firms with in-house development staffs tend to reason about the cost of software projects as a function of the salaries of the folks tasked with the work.

Of course, if you’re a veteran at managing software projects and teams, you realize that there’s more to the total spend than just the cost of the labor.  No doubt you factor in the up-front and licensing cost of the tools you use to develop the software as well as the cost of the hardware on which it will eventually run.  You probably even factor in the cost of training users and operations folks, and paying maintenance programmers to keep the lights on.

But there are other, more subtle costs that I’d like to discuss — costs related to your approach to software development.  These are variable costs that depend on the nature of the code that your team is writing.

Technical Debt

To really get at the total cost of software ownership requires an understanding of the concept of technical debt.  To communicate this concept, I’ll use an analogy rather than talking about software.  Imagine that you’ve cooked dinner, and you’ve used a whole lot of different dishes and utensils, all of which are now piled haphazardly in the sink.  They’re dirty and covered with drying food debris that, left untended, will make them very hard to clean.

DirtyDishes

Read More

Dec
27

By

Refactoring is a Development Technique, Not a Project

Category: Language Agnostic Tags: , , | 37 Comments

Editorial note: I originally wrote this post for the NDepend blog.  Go check it out over there and stay for a while to look around.  If you like posts about code analysis, metrics, and the business of software development, you’ll like the collection of posts there.

One of the more puzzling misconceptions that I hear pertains to the topic of refactoring. I consult on a lot of legacy rescue efforts that will need to involve refactoring, and people in and around those efforts tend to think of “refactor” as “massive cleanup effort.”  I suspect this is one of those conflations that happens subconsciously.  If you actually asked some of these folks whether “refactor” and “massive cleanup effort” were synonyms, they would say no, but they never conceive of the terms in any other way during their day to day activities.

Let’s be clear.  Here is the actual definition of refactoring, per wikipedia.

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior.

Significantly, this definition mentions nothing about the scope of the effort.  Refactoring is changing the code without changing the application’s behavior.  This means the following would be examples of refactoring, provided they changed nothing about the way the system interacted with external forces.

  • Renaming variables in a single method.
  • Adding whitespace to a class for readability.
  • Eliminating dead code.
  • Deleting code that has been commented out.
  • Breaking a large method apart into a few smaller ones.

I deliberately picked the examples above because they should be semi-understandable, even by non technical folks, and because they’re all scalable down to the tiny.  Some of these activities could be done by a developer in under a minute.  These are simple, low-effort refactorings.

Let’s now consider another definition of refactoring that can be found at Martin Fowler’s website.

Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant.

I took the wikipedia definition and used it to suggest that refactorings could be small and low-effort.  Fowler takes it a step further and suggests that they should be small and low effort.  In fact, he suggests that they should be “too small to be worth doing.”  That’s fascinating. Read More

Dec
20

By

Bringing Objectivity to Clean Code

Category: Language Agnostic Tags: , | 6 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  Please go check it out over there and take a look around at the content while you’re at it.  NDepend is one of the most indispensable tools in my toolbox.  

If you want to stir up a pretty serious amount of discussion-churn, wander over to where the software developers sit and ask for a consensus definition of “clean code.”  This probably won’t start a religious war — it’s not like asking for consensus on the best programming language or development tool.  You’ll probably find a lot of enthusiastic agreement with different flavors of the same basic concept.  This is true among luminaries of the field, as quoted here on DZone, and it’s most likely to be true in any given shop.

There will be agreement on the broad concepts and inevitable debate as the points become of a finer grain.  Developers can all agree that code should be “maintainable” and “easy to read” but you might get a bit of fragmentation around subjects like variable naming or relative compactness and ‘density’ of code.  Have the developers look at a bit of code and ask them if it could be “cleaner” and you’ll probably get an array of responses, including potential disagreement and thrash.  This will become especially true if they get hung up on cosmetic particulars like indentation, bracket placement, and casing.

So where does that leave us, exactly, when asked the deceptively simple question, “is this clean code?”  Programmers can arrive at a broad consensus on how to answer that question, but not necessarily on the answer itself.  They’ll all say, “well, it’s clean if it’s readable,” but some might give a particular bit of code a thumbs up while others give it a thumbs down.  If you’re a developer, this can be fun or it can be frustrating.  If you’re a non-technical stakeholder, such as a director, project manager, tester or business analyst, it can be confusing and maddening.  “So is this code good or not!?”

Enter the Coding Standards Document

When enough people with “manager” in their title are maddened, things get done.  Most commonly, this takes the form of the iconic “coding standard.”  The coding standard makes things blissfully cut and dried.

IndustryStandard

  • Thou shalt use camelCasing.
  • Thou shalt use tabs instead of spaces.
  • Thou shalt use verbs when naming methods and nouns when naming types.
  • Thou shalt not omit curly brackets for any control flow statements.

Read More

« Older Posts
Newer Posts »