DaedTech

Stories about Software

By

CodeIt.Right Rules, Explained Part 3

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, take a look at CodeIt.Right and see how you can automate checks for and enforcement of these rules.

In what has become a series of posts, I have been explaining some CodeIt.Right rules in depth.  As with the last post in the series, I’ll start off by citing two rules that I, personally, follow when it comes to static code analysis.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

It may seem as though I’m playing rhetorical games here.  After all, I could simply say, “learn the reasoning behind all suggested fixes.”  But I want to underscore the decision you face when confronted with static analysis feedback.  In all cases, you must actively choose to ignore the feedback or address it.  And for both options, you need to understand the logic behind the suggestion.

In that spirit, I’m going to offer up explanations for three more CodeIt.Right rules today.

Read More

By

Choosing Among Text Editors and IDEs

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at their offerings for monitoring all of your production concerns and infrastructure.

Few subjects in programming can get as contentious as quickly as, “what should I use to edit my code?”  Before you even get to the subject of “which one,” vigorous debates emerge over “what kind?”  This cordial Quora question with roughly 6 billion answers serves as an example of this.  Text editor or Integrated Development Environment (IDE)?

Only after that perilous decision do you arrive at the “which one debate.”  So furious has this debate proved that Wikpedia has an “Editor War” entry.  It describes the choice between the Emacs and VI editors.  The usage of “war” is a joke.  But only kind of.

So against this backdrop, you might regard the choice as one fraught with peril.  Pick incorrectly and risk the scorn of your peers.  That’s a joke.  But only kind of.

Fortunately, for the purposes of guidance, at least, I count myself a pragmatist mercenary.  In other words, I come from the relatively small camp of software developers without much strong preference about any of it.  I have spent years with each of the following: Visual Studio, Eclipse, IntelliJ, Emacs, Pico, Nano, Scite, SublimeText and Notepad++.  And I’m probably forgetting some.  All have their perks and foibles, but I prefer to keep my options open and let context guide me.

So, face with the need to pick new tooling, how should you handle it?  Today, I’ll offer some advice on heuristics for selecting an IDE or text editor.

Make a Quick List of Your Needs

First things first.  Do what you would do when contemplating any sort of consumer decision.  Make a list of your needs and wants.

For instance, say you were buying a refrigerator.  You’d need a certain size to fit your space, and you’d need a certain amount of storage capacity.  You might then want a chrome finish and an ice maker.  Contemplate the tool you’ll use for writing code in this same fashion, for starters.  You may have non-negotiable needs around operating system and programming language, and more fluid wants around features.

But also bear in mind context.  For example, do you specifically need a tool to work on one specific project at the office?  Or do you want something versatile that you’ll use everywhere, across various languages and technologies?

Now, combine these two lines of thinking and you will probably have narrowed the field considerably.  And you need to narrow the field, since a surprisingly daunting number of options exist out there.  Easier to choose among 2 or 3 than from hundreds.

Read More

By

Computing Technical Debt with NDepend

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, take a look at the newest version of NDepend and its options for helping you quantify tech debt.

For years, I have struggled to articulate technical debt to non-technical stakeholders.  This struggle says something, given that technical debt makes an excellent metaphor in and of itself.

The concept explains that you incur a price for taking quality shortcuts in the code to get done quickly.  But you don’t just pay for those shortcuts with more work later — you accrue interest.  Save yourself an hour today with some copy pasta, and you’ll eventually pay for that decisions with many hours down the road.

So I say to interested, non-technical parties, “think of these shortcuts today as decisions upon which you pay interest down the line.”  They typically squint at me a little and say, “yeah, I get it.”  But I generally don’t think they get it.  At least, not fully.

Lack of Concreteness

I think the reason for this tends to come from a lack of actual units.  As a counterexample, think of explaining an auto loan to someone.  “I’m going to loan you $30,000 to buy a car.  With sales tax and interest factored in, you’ll pay me back over a 5 year period, and you’ll pay me about $36,000 in total.”  Explained this way to a consumer, they get it.  “Oh, I see.  It’ll cost me about $6,000 if I want you to come up with that much cash on my behalf.”  They can make an informed value decision.

But that falls flat for a project manager in a codebase.  “Oh man, you don’t want us to squeeze this in by Friday.  We’ll have to do terrible, unspeakable things in the code!  We’ll create so much tech debt.”

“Uh, okay.  That sounds ominous.  What’s the cost?”

“What do you mean?  There’s tech debt!  It’ll be worse later when we fix it than if we do it correctly the first time.”

“Right, but how much worse?  How much more time?”

“Well, you can’t exactly put a number to it, but much worse!”

And so and and so forth.  I imagine that anyone reading can recall similar conversations from one end or the other (or maybe even both).  Technical debt provides a phenomenal metaphor in the abstract.  But when it comes to specifics, it tends to fizzle a bit.

Read More

By

Automation and the Art of Software Maintenance

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 CodeIt.Right for automating your code review process.

I have long since cast my lot with the software industry.  But, if I were going to make a commercial to convince others to follow suit, I can imagine what it would look like.  I’d probably feature cool-looking, clear whiteboards, engaged people, and frenetic design of the future.  And a robot or two.  Come help us build the technology of tomorrow.

Of course, you might later accuse me of bait and switch.  You entered a bootcamp, ready to build the technology of tomorrow.  Three years later, you found yourself on safari in a legacy code jungle, trying to wrangle some Sharepoint plugin.  Erik, you lied to me.

So, let me inoculate myself against that particular accusation.  With a career in software, you will certainly get to work on some cool things.  But you will also find yourself doing the decidedly less glamorous task of software maintenance.  You may as well prepare yourself for that now.

The Conceptual Difference: Build vs Maintain

From the software developer’s perspective, this distinction might evoke various contrasts.  Fun versus boring.  Satisfying versus annoying.  New problem versus solved problem.  My stuff versus that of some guy named Steve that apparently worked here 8 years ago.  You get the idea.

But let’s zoom out a bit.  For a broader perspective, consider the difference as it pertains to a business.

Build mode (green field) means a push toward new capability.  Usually, the business will regard construction of this capability as a project with a calculated return on investment (ROI).  To put it more plainly, “we’re going to spend $500,000 building this thing that we expect to make/save us $1.5 million by next year.”

Maintenance mode, on the other hand, presents the business with a cost center.  They’ve now made their investment and (at least partially) realized return on it.  The maintenance team just hangs around to prevent backslides.  For instance, should maintenance problems crop up, you may lose customers or efficiency.

Read More

By

Competing with Software Consulting Companies

Thanks, everyone, for sending in your reader questions!  I’m flattered by how many folks have submitted and definitely have a healthy backlog from which to choose.  Today, I’m going to answer one about competing with software consulting companies.

I believe this question came from a post I wrote two weeks ago, about speaking to your buyers, rather than to peers.  We as software developers seem to love to speak to our peers.  We speak at conferences and write blog posts for the love of the game, without realizing that impressing peers is unlikely ever to pay the bills.  So in that post I talked about how to speak instead to buyers through your blog.

Here’s the follow up question.  (He actually provided more context, which I’ve elided)

What motivates buyers to buy? In my experience, the big companies buy from other big companies — ones with infrastructure and support in place. Starting off, lest we share the fate of Ahab, we NEED to chase the smaller fish to cut our teeth in business. So, for the beginner chasing smaller fish, isn’t it more important to compete on price, given small fish don’t have the capital of big firms?

There’s a lot to unpack here, in terms of explanations.  So let me start out by drawing a meaningful distinction.  In that previous post, I talked specifically about freelance software developers.  But here we seem to be talking instead about consulting.  Or, at least, we’re talking about someone with a defined specialty.

Generalist Freelancers Don’t Compete with Firms… or Really Anyone

Why do I infer that we’re talking about someone already specialized?  Well, first of all, that was the whole point of my previous post.  But, beyond that, getting work as a generalist freelance software developer is too generic for the question to make much sense.  You might as well talk about how every maker of bottled drinks in the world could compete for a guy named Steve who’s in a gas station right now and thirsty.  It’s too generic a transaction to bother considering it as appropos of anything beyond the moment.

If you’re a software developer that does web apps using ASP MVC, Javascript, and C#, you’re conceptually competing with hundreds of thousands of people for every gig that you get.  And, worse, you’re competing with all of them via the interview process.  And job interviews basically just amount to picking people randomly and retroactively convincing yourself that there was a method to the madness.  So, as a freelance supplicant to the interview process, you’re kind of just playing game after game of roulette until your number comes up.  Or, you’re one of a hundred soft drinks and iced teas, hoping that Steve feels like something grape flavored and carbonated.

When you're a random soda, you're not competing with software consulting companies

To put a more emphatic point on it, think of it this way.  As a generalist freelance software developer, you needn’t bother thinking about your competition.  Your competition is too nebulous, and low leverage opportunities too plentiful to bother.  Just play a numbers game.  Throw your resume at contract matchmakers and recruiters, and line up regular interviews for yourself.  That gets enough people into the gas station that one of them feels like grape soda.

Read More