DaedTech

Stories about Software

By

Preemptively Identifying Dead Seas

Today, I’m going to try to tie various strands of my life together into one lanyard of efficiency.  I haven’t done a reader question for a while, so I’ll change that today.  In this post, I’ll offer a terminology nod to dead seas, a now-defunct term that became one of my favorites.  The best context I can now offer lies here, in a post of mine, summarizing it.

A few months back, I made a post on NDepend called, “What to do When Your Colleague Creates Spaghetti Code.”  In this post, I described a caricature that I randomly named Bill, who you might recognize as sort of a quintessential expert beginner.  I subsequently received a reader question about this subject.

How can I tell if the company interviewing me has a “Bill?” (i.e. “How can I preemptively identify expert beginners?”)

Well, I’ll take a crack at that.

Expert Beginner Primordial Soup

I think that a meaningful examination of this question requires us to look at the conditions that give rise to such archetypes.  In the original series/book, I cover part of it.  The organization must draw sort of a neat little box around the techie group and then put an advanced beginner in charge.  From there, the concoction needs to simmer in a nicely insular environment, in which the budding expert beginner receives no real negative feedback, second guessing, or industry exposure.

But this assessment focuses entirely on the software development organization.  An ensconced expert beginner reigning over some miserable, backward fiefdom requires “the business” as an accomplice.  Simply put, it requires the operational laziness to allow your business to be ruled by an unaccountable “expert” operating with utter opacity.

Expert Beginner Hut

Imagine you started a pizza shop and hired a pizza chef to run the kitchen.  Then imagine that you completely delegated the cooking to the chef, as you should.  Life treats all of you well for a while and you develop some business.

But now complaints from customers start to come in about the taste and presentation of the pizza.  “My pizza was incredibly salty and all of the pepperoni was isolated to three slices!”  When you bring this problem to the chef, he tells you that such is life when it comes to making pizza—and, also, get out of the kitchen.  You don’t taste the pizzas coming out or look at them or launch any sort of investigation when his pizza chef assistants serially quit, muttering about his incompetence.  You just count the inbound trickles of revenue and assume that’s as good as it gets.

Read More

By

Expert Beginner Store Kickstarter (And Giveaway!)

Check it out: the Expert Beginner has a kickstarter page!  But before you go, if you’re interested in details and some free swag, read on.

The Expert Beginner is Getting a Store…Maybe

People seem to enjoy the Expert Beginner—well, the satire anyway.  I imagine they don’t enjoy the real life version, walking around and lecturing you about the proper use of their tortured frameworks.  Instead, we’re talking about this guy:

My wife and I (though, mainly her, and thanks to her for all of the hard work on this) have decided to see if people would be interested in adorning themselves or their offices (okay, who are we kidding, cubicles) with themed merchandise.

The goal of the Kickstarter campaign is to fund the creation and seeding of an online store that will sell this merchandise. The things we’re planning to stock the store with so far are sticker, mugs, and—best of all– extremely comfortable shirts.  Seriously, I actually wear mine on weekend flights, which means it’s pretty much the most comfortable thing I own.

 

If we’re funded, we can supply this merchandise indefinitely! If not, you might be on your own for making Expert Beginner shirts. (We promise not to sue you if we fall short and you want to pick up the torch.)

The campaign will end January 5th, but if you’d like to contribute, please don’t wait until then. Apparently, projects that gain a lot of interest in the beginning are more likely to be promoted and rank higher in searches on Kickstarter. We ask that you visit the page and donate now to jumpstart the campaign. If you’re one of the first to donate, you have the chance at some early bird rewards, including mugs and shirts given for lower donation amounts.

Again, here’s the link to visit the Kickstarter Campaign Now

There’s also a reward for a $150 donation where you can get not only all the merchandise offered but also an hour on the phone with me to talk about whatever you like. I get a lot of reader questions for the blog, and in general, about a variety of subjects.  With those, you’re sort of at the mercy of my natural posting cadence and attention span.  With this donation option, you have my undivided attention for an hour, which is even longer than the time I donate at startup office hours.

If you can’t donate any money, you can still help! Please consider sharing this blog post with your social networks by using the usual buttons at the end of the post.   And you can enter our giveaway by sharing with your network via Rafflecopter.

Read More

By

Rewrite or Refactor?

Editorial Note: I originally wrote this post for the NDepend blog.  You can find the original here, at their site.  While you’re there, take a look at some of the other posts and announcements.  

I’ve trod this path before in various incarnations, and I’ll do it again today.  After all, I can think of few topics in software development that draw as much debate as this one.  “We’ve got this app, and we want to know if we should refactor it or rewrite it.”

For what it’s worth, I answer this question for a living.  And I don’t mean that in the general sense that anyone in software must ponder the question.  I mean that CIOs, dev managers and boards of directors literally pay me to help them figure out whether to rewrite, retire, refactor, or rework an application.  I go in, gather evidence, mine the data and state my case about the recommended fate for the app.

ProjectManager

Because of this vocation and because of my writing, people often ask my opinion on this topic.  Today, I yet again answer such a question.  “How do I know when to rewrite an app instead of just refactoring it?”  I’ll answer.  Sort of.  But, before I do, let’s briefly revisit some of my past opinions.

Getting the Terminology Right

Right now, you’re envisioning a binary decision about the fate of an application.  It’s old, tired, clunky and perhaps embarrassing.  Should you scrap it, write it off, and start over?  Or, should you power through, molding it into something more clean, modern, and adaptable.  Fine.  But, let’s first consider that the latter option does not constitute a “refactoring.”

A while back, I wrote a post called “Refactoring is a Development Technique, Not a Project.”  You can read the argument in its entirety, but I’ll summarize briefly here.  To “refactor” code is to restructure it without altering external behavior.  For instance, to take a large method and extract some of its code into another method.  But when you use “refactor” as an alternative to “rewrite,” you mean something else.

Let’s say that you have some kind of creaky old Webforms application with giant hunks of gnarly code and logic binding the GUI right to the database.  Worse yet, you’ve taken a dependency on some defunct payment processing library that prevents you from updating beyond .NET 2.0.  When you look at this and say, “should I refactor or rewrite,” you’re not saying “should I move code around inside this application or rewrite it?”  Rather, you’re saying, “should I give this thing a face lift or rewrite it?”

So let’s chase some precision in terms here.  Refactoring happens on an ongoing and relatively minor basis.  If you undertake something that constitutes a project, you’re changing the software.  You’re altering the way it interacts with the database, swapping out a dependency, updating your code to a new version of the framework, etc.  So from here forward, let’s call that a reworking of the application.

Read More

By

The Journeyman Idealist: Architect of Programmer Paycuts

A couple of months ago, I mentioned that I’d be featuring more cross posts so that I could concentrate on my book.  I’ve lived up to that, mixing in the occasional answer to a reader question with posts I’ve written for other sites.  I haven’t queued up a good old fashioned rant in a while, but I think it might be time.

I want to start talking about topics from the book, and this particular topic, the “journeyman idealist” has relevance to a number of different, random conversations I’ve heard of late.  Don’t worry if you don’t know what “journeyman idealist” means — you shouldn’t because I made that up while writing my book.  And I’ll get to that and to our self-defeating pay tendencies a bit later.

Hourly Billing

Recently, I have consumed a great deal of content related to freelancing, consulting, and billing models.  This includes the following items, for those interested.

As I fall further into this rabbit hole, I become increasingly convinced that billing by the hour for knowledge work is a pile of fail.  Jonathan Stark of “Ditching Hourly” makes the case more eloquently in this episode, but I’ll offer a tl;dr.

Let’s say that a prospective client comes to you and says, “I want you to build me a website.”  Great!  Let’s do some business!

HighFive

Hourly Billing as a Zero Sum Game

At this point, you begin to think in terms of cost and how high you can go above it.  For the purpose of your business, this means “what is the minimum amount for which I will do this project?”  The client begins to think in terms of value and how far they can go below it.  For them, this means “what is the maximum amount I can pay and still profit?”  Perhaps you won’t build the site in question for less than $10,000 and the client needs the figure to be less than $100,000 for the venture to bring a profit.  Thus if you agree on a price between $10,000 and $100,000, you both benefit, though the amount of the benefit will slide one way or the other, depending on how close to each end point you settle.

If you were selling websites as commodities, you’d haggle, then settle on price, as with a used car.  But building custom websites by the hour differs substantially.  In that world, you strike a deal without agreeing to price.  You just both hope that when the dust settles, the price tag falls in the range of mutual profit, and no lawsuits commence.  But within that range, each party hopes for a different end of the spectrum.  And what’s more is that neither party knows the other’s figure.  You know only that you need more than $10K and client knows only that it needs less than $100K.

As the website provider, you want the project to take as long as possible.  It needs to go sailing past $10K, and hopefully as close to client’s upper bound as possible.  The less efficiently you work — the more hours it takes to build the site — the better your financial outlook.

Read More

By

Avoid these Things When Logging from Your Application

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, sign up for the service and check it out.

It seems almost strange to talk about avoiding things while logging.  After all, logging is your last line of defense or your salvation in many cases.  Some crazy bug in the field that shows up every third full moon?  An external auditor looking at your app’s runtime behavior?  Logging to the rescue.

So naturally, is stands to reason that you would want to log just about everything your application.  Whenever there’s any doubt, slam a logger call in there and let log level sort out the details.  You can always filter logs, but you can’t magic stuff into them after the fact.  So why, then, talk of avoidance?

wizard

Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems.  You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it.  You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.

So what are these problems, and how to avoid them?  Let’s take a look at some things that can come back to bite you.

Read More