DaedTech

Stories about Software

May
25

By

Solve Small Problems

Category: The Life of a Programmer Tags: | 5 Comments

Editorial Note: I originally wrote this post for the Infragistics blog.  Go check out the original at their site.  While you’re there, go check out their developer tools and controls.

It’s fun to think of great moments in the history of science, particularly the ones that have a memorable anecdote attached to them.  In the 3rd century BC, a naked Archimedes ran down a city street, screaming Eureka, because he had discovered, in a flash, how to measure the volume of irregular solids.  In the 1600s, a fateful apple bonks Issac Newton on the head, causing him to spit out the Theory of Gravity.  In the early 1900s, another physicist is sitting around, contemplating the universe, when out pops E=MC^2.

Newton Getting Bonked with an Apple

These stories all share two common threads: they’re extremely compelling and entirely apocryphal.  As such, they make for great Disney movies, but not such great documentaries.  Point being, we as humans like stories of “eureka moments” and lightning bolt inspiration much better than tales of preparation, steady work, and getting it right on attempt number 2,944, following 2,943 failed attempts.

But it goes beyond just appreciating the former type of story.  We actually manufacture them.  Perhaps the most famous sort of example was Steve Jobs’ legendarily coy, “oh yeah, there’s one more thing” that preceded the unveiling of some new product or service.  Jobs and Apple were masters of “rabbit from the hat” marketing where they’d reveal some product kept heretofore under wraps as though it were a state secret.  All that is done to create the magic of the grand reveal — the illusion that a solution to some problem just *poof* appeared out of thin air.

Unrealistic Expectations

With all of this cultural momentum behind the idea, it’s easy for us to internalize it.  It’s easy for us to look at these folk stories of scientific and product advancement and to assume that not having ideas or pieces of software fall from us, fully formed and intact, constitutes failure.  What’s wrong with us?  Why can’t we just write that endpoint in one shot, taking into account security, proper API design, backward compatibility, etc?  We’re professionals, right?  How can we be failing at this?

You might think that the worst outcome here is the ‘failure’ and the surrounding feelings of insecurity.  But I would argue that this isn’t the case at all.  Just as the popular stories of those historical scientists are not realistic, and just as Apple didn’t wave a magic wand and wink an iPod Nano into existence, no programmer thinks everything through, codes it up, and gets it all right and bulletproof from the beginning.  It simply doesn’t happen.

Read More

May
23

By

The Role of Log Files in Experiments

Category: The Life of a Programmer Tags: , |

Editorial Note: I originally wrote this post for the LogEntries blog.  Head over to check out the original at their site.  LogEntries provides a service that allows you to centralize, monitor, and search your log files, so if you’re interested in logging and related topics, there is a lot to check out.

You have heard, no doubt, of the Lean Startup.  If you need a refresher to place the name, it’s a book, but it’s also a business trend with such momentum as to have a website advertising it as a “movement.”  And, frankly, that advertisement is hardly a stretch.  The title and the terms coined in it are on everyone’s lips in the tech industry these days because people at companies of all shapes and sizes want to capture some of that startup magic.

For instance, it’s pretty likely that you’ve heard a process described as “lean,” and it’s a veritable certainty that you’ve heard the term “minimum viable product” tossed around at some point or another.  You may even have heard these terms used correctly.  I say this because the use of these terms has become so ubiquitous among the book’s readers that non-readers adopt them as well and map their own situational contexts onto them.  Definitions drift.  “Minimum viable product” has come to mean “beta” or “prototype” and “lean” is a hipper, newer version of “agile” that has something to do with Toyota, or something.

But if you peel back a layer from breathless use of buzzwords, you’ll find genuine, serious substance underneath.  To summarize the Lean Startup in a ridiculously short sound byte, I would offer, “apply the scientific method to your business.”  And that’s an extremely powerful concept.

You’ll note that there’s nothing in my description about startups, per se, and that’s intentional.  As Eric Ries argues in the book, there’s nothing to say that the same approach can’t be leveraged within large, established businesses.  He even gives a number of examples of exactly that application.  Make no mistake; the Lean Startup approach has lessons for you no matter what your business and no matter how well-established.

Business, Science, and Software

For me, and for most reading, our business is the business of software.  The question thus becomes, “how can we apply the scientific method to building software?”

To do that, let’s consider the scientific method a bit more formally.  Here is what it involves, quoted from the linked page.

Read More

May
17

By

Calculating the ROI of NDepend

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

Editorial note: I originally wrote this post for the NDepend blog.  Head over to their site and check out the original.  While you’re there, take a look at the other posts and the offering to be had.

Years ago, I discovered NDepend and downloaded it for a trial.  At the time, I found myself working in a .NET shop where a lot of developers worked in the same large WPF codebase.  Code reviews were mandated, debates were frequent and impassioned, and global variables were everywhere, to the dismay of only some of us.  There was an entrenched majority that favored (or at least didn’t mind) a highly procedural style of writing object-oriented software, and nobody seemed able to put their fingers on why most feature development there had slowed to a crawl.

ScaryComputer

I was new to the group and had to pick my battles, particularly with people that had been there a long time.  Developers who favored automated testing and craftsmanship principles were in the minority there and had a history of leaving out of frustration, so I knew it’d be a challenge, and I went looking for help.  Among other things, I found NDepend and, after installing a trial, I recognized the power of the tool.

I recognized that it could help me as an objective, unbiased partner in making my arguments, but I also recognized that the way I approached code and architecture would never be the same.  The ability to visualize architecture in real time, the ability to treat code as queryable data, the metrics, the statistics, the well thought-out code warnings… it was a game-changer for me.  I just needed to convince my manager to let me spend a few hundred dollars to convert my trial version into a paid version.

It turned out this wasn’t hard, at least for me.  I had the good fortune of working for a company that appropriated a tools and learning budget for each individual developer, meaning all I had to do was declare that I wanted some of my total spend to go toward NDepend.  I did it without blinking.  But it might be that you aren’t as lucky.  Maybe you find yourself in a similar position to mine back then, but wanting to convince your manager that this powerful tool is indispensable because you don’t have a discretionary tools budget.

ROI: The Language of Management

I think I can help you here.  After all, I did leverage my experience running an IT department into a Plurlasight course about how to lobby your managers for practices and tools.  And the key to making a business case for anything, NDepend included, is to talk in terms of profits and losses, rather than in terms of, “it’s awesome, and it has all these graphs, and it shows me these rules, and CQLinq is the coolest thing ever, and…”  You get the idea.  NDepend’s coolness factor isn’t going to convince your manager to buy it for you.

Read More

May
8

By

Github and Code Review: A Quiet Revolution

Category: The Life of a Programmer Tags: , |

Editorial Note: I originally wrote this post for the SmartBear blog.  Go check out the original here, at their site.  Stick around and check out some of the other authors and posts over there if you’re so inclined.

When the winds of change blow through the programming world, they don’t necessarily hit everyone with equal force.  The start-up folks cranking out reams of Ruby code on their Macs probably feel a gale-force headwind, while a Software Engineer III toiling away in Java 1.5 for some Fortune 500 bank might feel only the slightest breeze.  But on a long enough timeline, the wind changes things for everyone.

Github has proven nothing short of a revolution for a lot of small, nimble organizations, startups, and cutting edge companies.  For heavily regulated, locked down enterprises, this effect is certainly muted, but I would argue that its subtly perceptible nonetheless.  Github is changing a lot of things about software development, and this includes the nature of code review.

Let’s consider some properties of Github.

Social Coding

Github is often described as a social network for programmers.  The term “social coding” has even appeared in some of Github’s marketing material.  It is a platform meant, specifically, for maximum interaction.

Sure, Github is a vehicle for open source contributions, but that’s hardly a difference-maker for them.  Sourceforge was around for a long time and it would host source control for open source projects for free.  There have also been other communities oriented around contributions and code sharing, such as Code Project.  Github, however, came along and truly married social with coding, introducing feeds, followers, ubiquitous collaboration tools, and even a social network graph.  Having cute octopus buddies as their mascots probably didn’t hurt matters either.

HighFive

The result is an unprecedented amount of enthusiasm for global sharing of code.  20 or even 10 years ago, you probably would have hoarded source code of a side project.  You wouldn’t have wanted to give away your intellectual property and you’d probably also have been embarrassed until you could tidy it up to put your best foot forward.  Now the default is to throw your side work up on Github and show it off for the world and your followers to see.  Code is being shared as never before.

Read More

May
3

By

Applied Consultant Taxonomy to Prevent Confusion

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

A few posts ago, I proposed a taxonomy for software consultants.  My reasoning for doing so was that I wanted to attempt a bit of clarification.  As software has taken over the world, “consultant” is no longer singlehandedly up to the challenge of describing everyone working in software not associated with any particular domain.

So I proposed the terms software pro, specialist and consultant as a means of bringing some clarity.  At the end of that post, I also alluded to a future post, in which I would talk about the problems that crop up when one of these personas is mistaken for another.  This is that future post.

Having been in and around the consulting world for a long time now and having served time in all three of these roles, I’ve seen firsthand how weird and sometimes damaging confusion of these roles can be.  There are too many permutations of mistake for me to want to list all of them in a post, so I’ll stick to the ones that are the most common and interesting, in my opinion.

The Aggrieved Grunt

For better or for worse, rightly or wrongly, software pros are regarded as the grunts of the non-salaried software development world.  Consultants and specialists are hired in non-delivery and possible-delivery roles, respectively, which means that they’re being hired for their expertise.  Software pros are hired into delivery roles, and while their expertise may interest their clients, it’s their labor that’s being purchased.

DevOpportunityCost

A non-expert labor purchase has two interesting characteristics for our purposes here.

  1. It means that someone else, and not the software pro, is making the strategic decisions (i.e. “we’ve put together all the requirements and design specs and need you to code ‘em up”).
  2. It puts the software pro firmly on the hook for execution.

Significantly, the software pro’s charter looks a lot like the line-level developer’s charter.  After all, architects and team leads make strategic decisions, and managers supervise delivery rather than owning it.  The grunt coders on the team, by contrast, faithfully execute the strategic visions of others.  So if we map the consultant taxonomy to familiar team roles, consultants are roughly like managers, specialists are roughly like architects, and software pros are basically developers.

Read More

« Older Posts
Newer Posts »