Stories about Software


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


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


Be a Savvy Consumer: Software Licenses Explained

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 monitoring services for your important stuff in production.

If you share my worldview, the subject of software licenses will bore you to the very fiber of your being.  Seriously.  I got into the world of software because I like to build stuff.  So, when the building finishes and the time comes to argue about who is allowed to copy what, when, and where, I prefer to let the bureaucrats sort it out.

Unfortunately, however, I can’t always do that.  From time to time it matters to me in a business context, advising clients.  Likewise, if I start slapping things on Github (or selling them), at some point, I have to think about licensing.  But today, I want to talk about arguably the most common way to encounter licensing: as a consumer.

Software seems to run on pretty much everything these days, so the question of who owns what can get murky.  You might find yourself in possession of a piece of software that you shouldn’t have, whether you realize it or not.  Or, you might download something free to use, as a developer, only to smack into legalese preventing you from redistributing it.  As you consume software, it behooves you to understand a bit about it.

Now, I cannot possibly explain every licensing model in a single post.  That topic presents such complexity that folks built an entire website dedicated to helping you sort it out.  What I’ll do instead is offer a quick primer.  I’m going to give you a breakdown of software licenses in terms of copyright implications.  Copyright governs a content producer’s rights to reproduce, publish, and sell that content.  In our case, we’re talking about source code and the resultant software.

Read More


Recovering from a Mission Critical Whiff

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.

A career in software produces a handful of truly iconic moments.  First, you beam with pride the first time something you wrote works in production.  Then, you recoil in horror the first time you bring your team’s project to a screeching halt with a broken build or some sort of obliteration of the day’s source history.  And so it goes at the individual level.

But so it also goes at the team or department level, with diluted individual responsibility and higher stakes.  Everyone enjoys that first major launch party.  And, on the flip side, everyone shudders to recall their first death march.  But perhaps no moment produces as many hangdog looks and feelings as the collective, mission critical whiff.

I bet you can picture it.  Your group starts charging at an aggressive deadline, convinced you’ll get there.  The program or company has its skeptics, and you fall behind schedule, but you resolve to prove them wrong.  External stakes run high, but somehow your collective pride trumps even that.  At various points during the project, stakeholders offer a reprieve in the form of extensions, but you assure them you get there.

It requires a lot of nights and weekends, and even some all nighters in the run up to launch.  But somehow, you get there.  You ship your project with an exhausted feeling of pride.

And then all hell breaks loose.

Major bugs stream in.  The technical debt you knew you’d piled up comes due.  Customers get irate and laugh sardonically at the new shipment.  And, up and down the organizational ladder, people fume.  Uh oh.

How do you handle this?  What can you learn?

Read More


The Most Commonly Reinvented Wheels in Software

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, take a look at their developer tools and controls offerings — they’re quite extensive.

If you ever want to set off a heated argument among software developers, you could do worse than to ask about “build vs buy.”  This one touches the third rail to such an extent that it has many colloquial names attached to it.

If you want to see this debate in action, plenty of venues exist.  Developers may accuse one another of reinventing the wheel, only to hear that some wheels need reinventing for various reasons.  Opponents of the practice have even described it as a syndrome, called “not invented here syndrome.”  But I have also seen proponents turn the tables and call out “not ever invented here syndrome” to describe software shops that awkwardly buy when building makes more sense.

Suffice it to say opinions abound and no clear consensus exists.  The highly context-specific nature of a given example also muddies the waters.  What makes sense for your team in your situation may not apply to another team.

I’ve offered thoughts on navigating this issue in another post.  Today, I’d like to avoid controversy.  I won’t weigh in on whether reinventing wheels makes sense because it deepens your knowledge or whether it wastes time and money.  Instead, I’m just going to catalog the most frequent examples I see of wheel reinvention.  As a consultant that specializes in assessing codebases and application portfolios, I see a lot of code.  This gives me a bird’s eye view of what shops love to write themselves.

Read More