DaedTech

Stories about Software

Mar
14

By

So, You’ve Inherited a Legacy Codebase

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

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, have a look around at some of the other posts and sign up for the feed.

During my younger days, I worked for a company that made a habit of strategic acquisition.  They didn’t participate in Time Warner style mergers, but periodically they would purchase a smaller competitor or a related product.  And on more than one occasion, I inherited the lead role for the assimilating software from one of these organizations.  Lucky me, right?

If I think in terms of how to describe this to someone, a plumbing analogy comes to mind.  Over the years, I have learned enough about plumbing to handle most tasks myself.  And this has exposed me to the irony of discovering a small leak in a fitting plugged by grit or debris.  I find this ironic because two wrongs make a right.  A dirty, leaky fitting reaches sub-optimal equilibrium and you spring a leak when you clean it.

Legacy codebases have this issue as well.  You inherit some acquired codebase, fix a tiny bug, and suddenly the defect flood gates open.  And then you realize the perilousness of your situation.

While you might not have come by it in the same way that I did, I imagine you can relate.  At some point or another, just about every developer has been thrust into supporting some creaky codebase.  How should you handle this?

Read More

Jan
19

By

Collaborating with Outsiders to the Dev Team

Category: The Life of a Programmer Tags: , |

Editorial Note: I originally wrote this post for the SmartBear blog.  You can check out the original here, at their site.

Developer news sites, blogs, books, and tutorials tend to speak at length about how developers should collaborate with one another to maximize team effectiveness. The subject of how developers should collaborate with people outside of their team often gets shorter shrift, however.

Personally, I find this to be a shame.  I think it tends to reinforce the stereotype that developers do a poor job of human interaction and need an organizational layer of people to translate between them and normal humans.  I would prefer to live in a world where people didn’t draw distinctions between “the developers” and “the business” because it was simply assumed that software development was part of the business.

For this reason, I’d like to offer some thoughts on how you, as a developer, can most effectively collaborate with non-developers — people outside of your team.  I will offer the caveat that some teams, particularly Scrum teams, are cross functional and thus include non-developers in the team itself.  I understand that, but for the purpose of speaking to the broadest audience, I will presuppose that your team is specialized in the sense that it is made up exclusively of software developers.  Besides, if your team does include other disciplines, it isn’t as if advice on how to collaborate with those folks magically becomes invalid.

Before getting into specifics, I want to mention two universal principles.  The first I will call out only briefly now and not again because it should be common sense and go without saying.  But, in case it doesn’t, treat these colleagues with courtesy and respect.  They are intelligent knowledge workers that simply have a different specialty than you do, and you ought to treat them as such.  If you can’t do it simply as part of being a decent human being, do it because acting like a primadonna is career limiting.  The second principle I’ll mention is that, because these collaborators are intelligent knowledge workers with a different specialty, you should endeavor to learn from them to improve your own work.

Read More

Jan
17

By

Top Heavy Department Growth

Category: You Asked For It Tags: , , |

I’ve been somewhat remiss in answering reader questions lately.  Largely, I’ve lapsed because I’m choosing to focus on my upcoming book.  Nevertheless, I apologize for the lapse.  I do appreciate all the questions you folks send my way.  I’ll try to compensate today with this post about organizations engaging in top heavy department growth.

I’ll paraphrase this reader question because the specificity of the titles and information involved could make it sensitive if I didn’t take a couple of liberties.

I read your article about architect title over-specialization.  I’m a software developer with senior level experience.

Recently, my company has created “levels” above me.  I used to have only a dev manager above me.  But recently, the organization has brought in both new team leads under the dev manager and architects under a different manager.  Both take precedence over the existing developers.  These people now have authority to tell us what to do and they get to choose what they want to work on, leaving us with the leftovers.

I feel as if i’m being promoted down hill. Can you please advise?

How Companies Expand

If you’re up for it, I’ll offer a good bit of background reading to flesh out the terms.  If not, I’ll furnish minimal definitions here for reference.  A while back, I wrote a post describing the company hierarchy.  That post contains excerpts from my upcoming book, which you can pre-order and read on leanpub.

Here you have an apt illustration of the average company.  At the top, in executive roles, you have opportunistic individuals who define (and violate) the rules and culture of the company.  Then, in the middle, sit the idealists, who guzzle that same kool-aid and ask for more.  Finally, at the bottom toil the pragmatists, who roll their eyes at the company but put up with it for lack of better options.

Significantly, pyramids retain their stability by maintaining their shape.  Thus the most stabilizing growth pattern involves rewarding (over-promoting) loyal pragmatists, and hiring a bunch of grunts beneath them.  If you think of an existing pyramid that needs to get larger, you wouldn’t heap stuff on top.  Instead, you’d build from the bottom.  You’d pull some senior developers, make them architects or team leads to reward them hanging around, and hire a bunch of new grunts to report to them.

Read More

Jan
3

By

Resolutions Like You Mean It

Category: The Life of a Programmer Tags: , |

Let me start this off on an improbable foot by saying I’m not huge on the concept of New Years resolutions, per se.  But I do value reflection and improvement.  And if just after the winter solstice seems like a good time for it, don’t let me stop you.

Finding Feedback

Last fall, I began participating in a mastermind group.  If you have a W2, your employer will typically offer you rather paternalistic guidance under the heading of career development.  I call it paternalistic, since it generally assumes that your goals include working for the company forever, and emulating the people that have worked there forever.  But, set that aside, and you can often extract a bit of value from it.  For instance, you’ll get someone’s take on how to secure a promotion or get assigned to a better project.

If you go the solo consultant or entrepreneur route, nothing like this really exists.  I don’t think someone has used the words “exceeds expectations” in front of me for about 5 years.  This I attribute to the fact that nobody uses those words outside of the corporate performance review.  And I haven’t had one of those in half a decade.

A mastermind group, more or less, fills that gap.  A few people get together at some interval (weekly, for instance), brainstorm, share ideas, hold one another accountable, and offer mutual advice.  Pound for pound, this offers much more individual value than the corporate perf review/boss one on one because it focuses entirely on my goals, not my goals in the context of being a perpetual good solider.

Measure It

At one of the mastermind group calls, we laid out goals for 2017.  Not having done this before, I lurked more than participated, to see what sorts of goals these meant.  The other participants laid out real plans, with real numbers, to do things like change revenue by X% or shave Y% of time off of some operational concern.

I came to the table with vague notions of, “I want to spend less time in cold places.”  Part of this results from my tendency to let lifestyle goals dictate work arrangements.  But part of this comes from sloppiness and the consultant’s peril of not taking one’s own advice.

Read More

Dec
18

By

The Nature and Eventual End of the Journeyman Idealist

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

This is part 3 of the series about journeyman idealists.  You can read part 1 here, and part 2 here.

Hiring Ditch Diggers

We toil in an industry that loses sight of this basic problem, and no wonder.  In a simple scenario like that, we can reason about value.  But I’d like to employ an allegory to show how opaque that reasoning becomes at scale.  And in that opacity, the journeyman idealist reigns supreme.

Let’s say that I need to have a ditch dug in front of my house, and I have two competing laborers willing to do it.  The first one talks enthusiasticilly about soil aeration and the mineral properties of dirt in the area and whatnot.  He talks about the real craftsmanship that goes into ditch-digging and how people don’t realize that.  The other guy charges a few bucks less per hour, so I hire him.  How hard can it be?  And, besides, I can look out my window and see how it’s going.  If he fails and the ditch caves in or something, I can call the other guy that likes to ramble on about soil.

guy-digging-a-hole

But now imagine that I can’t actually see any of the progress as it happens, and I will only know if it went well when one day, either sewage backs up into my toilets or not.  Wow, okay.  Same labor proposition, but with opaque progress and all-or-nothing results.  Earthworm Jim now sounds more appealing.  I have no idea how Jim’s knowledge translates into money or outcomes, but I take it on faith.

Journeyman Idealist Ditch Diggers

Now imagine that instead of my house, I run a massive construction company and I’m building several developments simultaneously.  Jim is my digging foreman, and I trust him to make sure we dig ditches.  Jim asks people lots of questions about topsoil acidity and demands they estimate how many aphids could fit onto a leaf.  All of that seems kind of stupid to me, but what do I know?  The ditches get dug, so it must be working.  And, besides, for some reason every ditch digger around seems to want to work here because we have “interesting soil” and Jim uses that outsize demand to tell them that aphid-know-nothings like them deserve to start at a lower pay grade.

I have hired, in Jim, a journeyman idealist.  And he hires in and indoctrinates more of the same.

Read More

« Older Posts
Newer Posts »