DaedTech

Stories about Software

By

Easy to Miss Code Smells

Editorial Note: I originally wrote this post for the NDepend blog.  Please head over to the site and check out the original.  There’s a lot of great content over there, and, if you’re not familiar with NDepend, download a trial and try it out.

The concept of a code smell is, perhaps, one of the most evocative in our profession.  The name itself has a levity factor to it, conjuring a mental image of one’s coworkers writing code so bad that it actually emits a foul odor.  But the metaphor has a certain utility as well in the “where there’s smoke, there may be fire” sense.

In case you’re not familiar, a code smell is an observable feature of the code (the smoke) that often belies a deeper existing problem (the fire).  When you say that a code smell exists, what you’re communicating is “you may be justified here, but I’m skeptical – in my experience this is probably a design flaw.”

Smelly computer

Of course, accusing code of having a smell is only slightly less incendiary to the author than accusing code of being flat out bad.  Them’s fightin’ words, as they say.  But, for all the arguments and all of the righteous indignation that code smell accusations have generated over the years, their usefulness is undeniable.

No doubt you’ve heard of some of the most common and easiest to visualize code smells.  The God Class, Primitive Obsession, and Inappropriate Intimacy all come to mind.  These indicate, respectively a class in your code base doing way too much, a tendency to use primitive types when you should take advantage of classes, and a module or class that breaks encapsulation by knowing too many details about another.  The combination of their visual memorability and their wisdom has prodded us over the years to break things down, to create cohesive objects, and to preserve encapsulation.

I would argue, however, that there are many more code smells out there than the big, iconic ones that get a lot of attention.  I’d like today to discuss a few that I don’t think are as commonly known.  I’ll make the case for why, once you’ve mastered avoiding the well-known ones, you should watch for these as well.

Read More

By

The Business-Personal Value Continuum

While out on a jog recently, I found myself listening to an episode of .NET Rocks, in which the discussion covered the surprising percentage of developers still using Winforms and the general topic of using licensed controls written by third parties.  This started a train of thought in my head that might end in mild controversy, but I think it’s worth exploring a bit.

Two profiles (well, more like caricatures) of developer came to mind, standing in stark contrast to one another.  First is this Winforms developer that is more or less cobbling together spare parts to build applications. He uses a WYSIWYG editor, employs some kind of “database form wizard” to bind a GUI widget directly to a table, plops a slew of obscure third party controls into the code, and ships some kind of Franken-app not actually involving much code.  The second profile rounds out the dichotomy and consists of the foundational crafter.  This person builds her own tools and controls using low level language constructs and the command line, and assembles these works of art into ever-higher layers of abstraction until shipping a hand-crafted app.

If I’m running a business, give me the first person.

Undoubtedly, the crafter harbors a better, more fundamental grasp of the principles of computer science, and she undoubtedly offers the most versatility.  If she can build a compiler, use that to build a text editor, use that to build a source control system, use that to build a web server, and use that to build the sexiest, popping-ist, UX-friendliest website you’ve ever seen, she is the most employable, most full stackable programmer ever.  The business will never encounter a situation beyond her grasp.  But who cares, if the business just needs a checkbox added to a battleship gray, outdated Windows application?

Female Artist

I practice test driven development.  I rail against the evils of copy and paste programming.  I counsel clients on the dangers of technical debt and feature slow down.  I advocate wholesale for clean code.  And because of all these things, I understand that every single line of code you write is an incremental business liability.  So why would I take the cobbler over the crafter?  Don’t get me wrong — if I had to pick one of the two of them to write a given module, I would take the crafter.  But for approach, I would take the cobbler because the cobbler makes most of the code someone else’s problem while the crafter makes it all my problem.

What I really want is someone with the chops of a crafter and the reluctance to write more code than necessary of a cobbler.

Read More

By

Logs for SEO

Editorial Note: I originally wrote this post for the LogEntries blog.  You can check out the original here, at their site.  While you’re there, check out the features of their offering.

I write blog posts on a number of different sites that are not my own, and that is an exercise in pure writing joy.  I compose the posts, I submit them, and viola!  They’re published on nice-looking sites, promoted by people with reach, and read by many (hopefully) interested readers.  Life is good.

By way of comparison, when it comes to my own blog, life is not quite so simple.  On my own blog, I have to write the posts and manage all of the details that are abstracted away when I write for other sites.  So many things distract from content.

ShakespeareWriting

There are the major ancillary concerns like the site’s look and feel and following up on any downtime or outages.  There are minor ancillary concerns, like checking for typos, promoting the posts, and making sure no one is inappropriate in the comments.  And then there are enigmatic ancillary concerns, like search engine optimization (SEO).  My primary concern is content generation, however, so, even with my own site, I seek to abstract as much of this away as possible.

The Weird World of SEO

Let me start off by saying, emphatically, that I am not an SEO expert.  Frankly, it’s not a topic that particularly interests me in and of itself… at least not until I had to be interested in it.

I have a blog as part of my website, but from that same website, I offer information about my consulting practice and about books and products that I offer.  More readers translates into more engagement, which, in turn, translates into a better living for me.  And it was against this backdrop that I became interested in SEO by default.

SEO actually reminds me of the credit score concept, in which a mysterious agency uses a mysterious algorithm to compute a score that has a serious effect on your life.  The mystery and complexity of the algorithm and proprietary nature of the score, in turn, create a cottage industry of advice and services aimed at helping you get just a little bit better.

As a blogger and entrepreneur, this is the SEO world for me.  Google (and nominally other search providers) have secret sauce algorithms that figure out how to rank content based on its likelihood of being valuable to people using the search engine.  I don’t care much about these for their own sake, but I do wind up having to learn enough about how the whole thing works in order to make (what I hope are) informed decisions on how to position myself.  Oh, and I have to do that while not wasting a whole lot of time on it and veering into the land of diminishing returns.

Read More

By

Sources of Inspiration

A while back, I got a reader question that was extremely short and sweet.  It was, in essence, asking me about success that I’ve enjoyed.  Given that this is a subjective concern and that I wince at the prospect of self promotion (I’ve learned this is probably a matter of being an introvert), I’d rather deflect this and talk about things that have inspired me over the last number of years.  This post is about those sources of inspiration.

First, though, the reader question.

How did you get to where you are?

To answer that properly would require a good bit of introspection of the form, “where, exactly, do I think that I am.”  I’m not really prepared for that, not because I don’t like introspection, but because I’m pretty content with my life in these terms at the moment.  My life suits me well, but I wouldn’t presume to suggest that it suits others well.  This presents me with the challenge of answering the question, but without the typical, self-help template of “here’s what I did as a blueprint, and you can do it too!”

I think what would go better than that is to talk about some serious sources of inspiration over the last several years.  That way, rather than focusing on what particular things I’ve done, I can focus instead on what I’ve been trying to do and why.  This, I feel, will leave you in a better position to evaluate whether you want to understand “where” I am and whether you also want to be there.

For you mythology buffs, this is Sysiphus actually making it to the top of the hill.

In terms of format, I’m going to talk about four books that have helped me formulate and refine my more recent approach to life.  Using a good bit of wisdom from these books, I’ve gone from working as a software engineer to being an independent technologist.  My work is asynchronous, entirely remote (with some travel), and generally varied in nature.  This makes for a fun mix and it lets me live a pretty low key, mobile life.  All of this is no accident.

So, without further ado, here are the books that have contributed significantly to inspiring my choices.  I’ll describe them briefly, and then the impact they had upon my life.  Keep in mind that these are not in chronological order of my reading of them, but rather in the order I think makes sense to introduce them if you’re looking to pursue a similar path to mine.

Read More

By

How to Add Static Analysis to Your Process

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’e there, take a look at the other posts and download a trial of NDepend, if you’re so inclined.

As a consultant, one of the more universal things that I’ve observed over the years is managerial hand-waving.  This comes in a lot with the idea of agile processes, for instance.  A middle manager with development teams reporting into him decides that he wants to realize the 50% productivity gains he read about in someone Gartner article, and so commands his direct reports or consultant partners to sprinkle a little agile magic on his team.  It’s up to people in a lower paygrade to worry about the details.

To be fair, managers shouldn’t be worrying about the details of implementations, delegating to and trusting in their teams.  The hand-waving more happens in the assumption that things will be easy.  It’s probably most common with “let’s be agile,” but it also happens with other things.  Static analysis, for example.

Lumbergh

If you’ve landed here, it may be that you follow the blog or it may be that you’ve googled something like “how to get started with static analysis.”  Either way, you’re in luck, at least as long as you want to hear about how to work static analysis into your project.  I’m going to talk today about practical advice for adding this valuable tool to your tool chest.  So, if you’ve been meaning to do this for a while, or if some hand-waving manager staged a drive-by, saying, “we should static some analysis in teh codez,” this should help you get started.

What is Static Analysis (Briefly)?

You can read up in great detail if you want, but I’ll summarize by saying that static analysis is analysis performed on a codebase without actually executing the resultant compiled or interpreted code.  Most commonly, this involves some kind of application (e.g. NDepend) that takes your source code files as input and produces interesting output by running various analyses on the code in question.

Let’s take a dead simple example.  Maybe I write a static analysis tool that simply looks through your code for the literal string “while(true)” and, if it finds it, dumps, “ruh-roh” to the console.  I’m probably not going to have investors banging down my door, but I have, technically, written a static analysis utility.

Read More