DaedTech

Stories about Software

Dec
9

By

Preemptively Identifying Dead Seas

Category: Uncategorized, You Asked For It Tags: , , , | 2 Comments

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

Dec
2

By

The Journeyman Idealist: Architect of Programmer Paycuts

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

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

Oct
14

By

What to do when Your Colleague Creates Spaghetti Code

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

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 around and give NDepend a try.

I write for a number of different outfits and earn my living consulting around software and IT.  Because of the intersection of these three concerns — writing, offering advice professionally, and software — I field a lot of requests for advice on how to do the right technical thing without everyone around you shooting holes in it.  Consider an example.

“How can we get started with unit testing?”

Considered as a technical question alone, this invites a fairly obtuse response.  “First, write a unit test.  Second, run the unit test.”  Obviously, that’s not really what anyone is asking when they ask this question.

Instead, they want to know something orders of magnitude more complex.  “How can we overcome years of inertia, a nasty legacy codebase, Bill, who has been around for 40 years and hates everything new, and the fact that management doesn’t want to pay us to write ‘extra’ code… and then start unit testing?”  Oh, yeah, that.  Well, that’s complicated.

I frequently hear such apparently-innocuous-but-actually-complex questions about code quality.  “This idiot on my team is writing mountains of the most unmaintainable garbage imaginable — what should I do?”

spaghetti

Usually, this sort of question comes to me from people at client sites.  And, accordingly, I have to balance the answer that makes the most sense for the individual with the one that keeps the client’s best interests in mind.  The client pays my bill, and I have a charter to lower the cost of ownership and development of their code.

But when I’m in writer mode, and only the asker’s interests matter, I’l give a subtly different answer.  Today, I’d like to offer advice on what you should do in this situation.

Read More

Oct
5

By

Securing Yourself a Better Title

Category: You Asked For It Tags: , | 9 Comments

Tonight marked the vice-presidential debate and the start of the baseball playoffs.  With two spectator sports on television, I thought I’d draw some inspiration and answer a reader question about office politics.  This question came to me from a reader whose problem tracks back (in my opinion) to need for a better job title.  And it came in lengthy format, checking in about 1,100 words!

For the sake of both poster anonymity and brevity, I will summarize with as little information loss as possible.  My summary is as follows.

I finished a CS degree and took an entry level position.  From there, I took a job that involved writing code — automation around Selenium to be used by a QA group for testing.  I believe this mimics the role of Google’s “Software Engineer in Test.”  That said, the conferred upon me the title of “QA Engineer.”

For two years, I enjoyed the development work in this role and made inroads toward an advancement.  Before that happened, however, my company shuffled departments, and I found myself in a new part of the company, under a new boss.  This new boss only saw me for my title, rendering my progress moot.

I approached him about my situation and he agreed to put me on a more classic development team, but on a “probationary” basis.  He said that he’d consider a formal change in six months if I could work on defects and get my fix rate up to a certain number per week.  Six months later, at a review, he said that I had made definite progress, but that my rate of X per week was just not QUITE high enough and that we could talk again next year at performance review time.

What are my options?  What should I do next?  I feel that I’ve now fallen behind people of a similar, salary-wise, and I feel stuck in a rut.

GlumGuy

Title Matters

Let me start by offering a quick bit of context.  Recruiters and people offering you jobs with bad titles will tell you that titles don’t matter.  Don’t listen to recruiters and people offering you bad titles because titles do matter.

They matter because a job title counts as what I’ll call passive bargaining material.  When you navigate the waters of your career, you will have negotiation points where you look for more salary or benefits or whatever.  The actual negotiating constitutes the active component of this dance, and that matters.  But so does the passive portion: your previous/current title, salary, benefits, etc.

Don’t believe me?  If you’re a developer, cold-apply to a bunch of dev manager or director gigs.  No responses?  Try adding a fictitious 5 year stint as “Director of Software Engineering” to the top and try again.  Bet you get at least a few calls.

Read More

Sep
25

By

Defining Developer Collaboration

Category: The Life of a Programmer Tags: , | 1 Comment

Editorial Note: I originally wrote this post for the SmartBear blog.  Check out the original here, at their site.  While you’re there, take a look around at the pieces written by other authors as well.

A certain ideal of rugged individualism has always permeated programmer culture, at least in some circles. It’s easy enough for writing code to be a highly solitary activity. There’s a clear set of rules, output is a function of input, feedback is automated, and the profession tends to attract night owl introverts in many cases.

The result is a history punctuated by tales of late night, solo efforts where someone stares at a computer until overcome by sleep. Obsessed, brilliant hackers expend inconceivable efforts to bring amazing open source tools or useful libraries into existence. It squares with movies, popular culture, and our own knowledge of our profession’s history.

SuperFastTyping

And yet, how many significant pieces of software are developed this way anymore? This ideal was born into a world where complex software might have required 10 thousand lines of code, but does it carry forward in a world where 10 million lines are common? Even projects started by individuals on a mission tend to wind up on Github and to gather contributors like a snowball rolling down a mountain.

Today’s technical landscape is a highly complex, highly specialized, and highly social one. In a world where heroic individual contributions are increasingly improbable, collaboration becomes the name of the game. Like it or not, you need other people to get much done because the work and the breadth of knowledge tends to be too much for any one person.

Defining Collaboration for Developers

I’ll spare you the obligatory, “Webster’s Dictionary defines collaboration as…” It means what you think it means: people working together. I’d like, instead, to establish some axiomatic ground rules in applying the term to the world of software development.

The first requirement is, of course, that you need to have more than one human being involved to consider the effort to be collaboration. The mechanisms, protocols and roles can vary widely, but table stakes require more than one person.

The second requirement is that the participants be working toward a shared goal. Without this, a bunch of people in a coffee shop could be said to be ‘collaborating’ simply by virtue of colocation and the occasional, polite interaction. Collaboration requires multiple people and it requires them to be united in purpose for the activity in question.

A final and developer-oriented requirement is that the participants must be working on the same work product (i.e. codebase). Again, consider a counter-example in which iOS and Android developers could be said to be ‘collaborating’ since there are more than one of them and they’re united in the purpose of improving users’ smartphone experience. Their shared purpose has to bring them together to work on the same actual thing.

Really, though, that’s it. More than one person, united in purpose and working on the same thing, are necessarily collaborating. Whether they do it well or not is another matter.

Read More

« Older Posts
Newer Posts »