DaedTech

Stories about Software

By

Modularity on My Honeymoon

If you hadn’t noticed, I’ve been gone for the last couple of weeks.  I got married and went on a honeymoon and left the blog on auto-pilot, with scheduled cross posts of things I’d written for other blogs.  I figured this was better than providing no content and hopefully the posts and social media announcements synced up closely enough that I didn’t look ridiculous.

During the trip, I didn’t think a whole lot about software, per se, but I gave occasional thought to what I might say upon my return.  I think really good bloggers make cool segues out of trips and experiences.  You know, like  “I was gazing up at the Eiffel Tower and I couldn’t help but think of Liskov’s Substitution Principle.”  I’m not that good, so I didn’t come up with anything like that.  I was in France and Monte Carlo, and I ate a lot of cheese, saw a lot of sites, drank a lot of wine and spent a lot of time reading.  None of that reminded me of code or software, really.

An Idiot (Me) Abroad

In fact, the only technical lessons I could relate were birthed from my own stupidity.  I brought my Mac Book pro along, but, incredibly, managed to forget its charger.  Upon arrival at our hotel in Paris, jet lagged, I dug the laptop out of the bag to charge and discovered that this would be quite impossible.  Suddenly, the Mac’s 90% charge was an ominous harbinger of computing scarcity.  I’d have to ration, what, like 3 or 4 hours of latpop usage for the entire trip? Read More

By

Managing to Avoid Cobras

Incentives are a funny thing.  Done well, they can spur your team to productivity and career-advancing, win-win situations.  Done not so well, they can create havoc.

As this point, I could offer up a dry explanation of the “law of unintended consequences,” but I’ll let Wikipedia do that.  Instead, I’ll tell you a quick story about something that came to be known as the “cobra effect.”  Snakes are clearly more interesting than laws.

In colonial India, the Brits in charge didn’t like the large number of venomous snakes that they encountered. So they did something that seems imminently sensible at first blush: they offered a bounty to locals for dead cobras.  At first, things went well.  Locals killed corbras, locals got their rewards, and the governing Brits saw a dip in cobra encounters.  But then the cobra encounters started to creep back up, even as the number of dead cobras turned in continued to climb.

Turns out, the locals had started breeding cobras specifically to turn them in and collect the reward.  Once the British government caught wind of this, they (predictably) terminated the reward program, and the erstwhile cobra breeders simply released the now-useless snakes. So the net result of this program turned out to be an increase in the cobras.  Ouch.

Beware of Cobras

When I tell you to beware of cobras, I’m not talking about looking out for snakes (though, clearly, if you live in an area with cobras, you should probably look out for them).  I’m talking about keeping an eye out for bad incentives.  For instance, if you’re managing a software department, do a thought exercise as to what might happen if you agreed to pay testers $5 extra for each bug they found and developers $5 extra for each bug they fixed.  At first, that probably seems like a good way to get them all to work a little extra and produce good results.  But, channeling the cobra example, can you spot what might go wrong?

This is the beginning of a post that I wrote for the NDepend blog.  Click here to read the rest of it.

 

By

Make the Complex Simple

For many years, I associated the concept of “making the complex simple” with teaching. And that’s certainly not wrong. We’re in an industry filled with complexity, both essential and accidental. To survive in this industry requires understanding essential complexity and eliminating accidental complexity, and novices struggle with this. As developers become self-sufficient, they figure out complexity reduction enough that they can mentor others in the concept. Once they get to the point of teaching concepts pretty seriously — giving conference talks, creating courses, coaching, etc. — it can definitely be said they’ve become good at “making the complex simple.”

Of course, it could also be said that the term applies to communications with non-technical stakeholders and not just teaching inexperienced developers. Think fast — how would you explain to the CIO who doesn’t have a programming background why you should stop delivering features for a couple of weeks in order to retrofit an IoC container onto your codebase? If you start saying things like “inject your dependencies” and “switch your database driver without recompiling,” you’re keeping the complex complex as the CIO stares blankly at you. Making it simple isn’t easy, is it?

To take complicated concepts and communicate them simply, with minimized loss of pertinent information, is a skill you could (and should) spend a lifetime improving. It requires overcoming the curse of knowledge, understanding your subject matter extensively, knowing your target audience’s world fairly well, being  adept at mapping concepts and creating analogies, communicating clearly and, oh yeah, often doing it all off the cuff. Piece of cake, right?

Hard though it may be, it’s a skill worth developing.

I originally wrote this post for John Sonmez’s site, Simple Programmer.  Click here to read the rest of my argument as to why you should develop this skill.

By

Salary Negotiation without Bridge Burning

Before the regular post, a bit of housekeeping.  I’m getting married tomorrow and then heading off for a honeymoon where I’ll be largely off the grid.  I’ve scheduled posts to go out during that time and social media blasts to announce them, but in case things get weird, know that the ship is on auto-pilot.  If you tweet/message/email me or submit questions, know that I won’t be back home and playing catch-up until late September.

With that out of the way, I’m going to make my last post before leaving a post about something people frequently ask me.  This actually isn’t a reader question submission, per se, but I’m asked about it enough that it might as well be.  If you’ll recall, a while back, I talked about how to negotiate with your employer by suggesting that you should negotiate for non-monetary perks with a lot more value than whatever pittance you’ll claw out of them.  But what if you really want or need more money?

I was reading this post on Simple Programmer by Xavier Morera the other day.  In it, he mentioned walking away from a job and having them offer to double his salary, and this struck a chord with me as a valuable lesson for how to negotiate with employers if what you really want is more money.  You’re probably thinking that a doubling of salary sounds outlandish, and, while that is unusual, it’s not as crazy as you think because of Xavier’s circumstances, which are likely different than yours.  They’re quite probably different because he wasn’t looking for the money and walked away from it.  You’re looking for it.

So how can you set yourself up to negotiate when you really want that money and you want to stick around the company for a while?

Remedial Opportunist Raise Negotiation

Something I still see people do that just makes me cringe is to secure a competing offer from another company and use it as raise leverage.  Often this happens after someone unsuccessfully pushes for more money, but they might just opportunistically go out and do it.  This is, strictly speaking, an opportunist move.  (If you’re not familiar with my definition of the company hierarchy, you should read about it to understand what I mean by “opportunist.”)  But it’s a move by someone who is bad at being an opportunist and probably destined for flameout followed by checked out pragmatism.  Opportunists are risk tolerant, but this type of leveraging is an extreme short term, prospect-killing play.

Put yourself in a manager’s shoes and imagine the conversation.  Bob saunters in, sits down and says, “so, I just got a really tempting offer from Initrode and it’s actually for 10K a year more than I make here.  I’d really like to stay, but it’s hard to leave that money on the table.  If you could match it… look, I’m sorry to put you in this spot, but it just sort of happened.”  What’s your next thought?

I’ll tell you what mine is in this situation.  “Yeah, it just ‘happened,’ huh, Bob?  You tripped, fell, called in sick here a couple of times, got dressed up in a suit, scheduled multiple rounds of interview with several people, received an offer letter, negotiated to a final offer and walked in here with it to show me?  Yeah, that’s a crazy coincidence!”  Bob is wearing a smarmy smile and insulting my intelligence.  This didn’t “just happen” — it was a calculated piece of leverage, executed at a time when Bob leaving would be an operational problem.  Bob’s strongest case for increased compensation was soft blackmail.

HighMaintenance

Read More

By

Musing on Agile’s Built In Caveat Emptor

First things first.  I’d like to thank the folks who submitted “Ask Erik” questions (I’m thinking I might need to come up with a title that’s not as lame — iterate all the things!)  I’m pleased with the results so far, and early returns on my hypothesis look good.  Interestingly, I received more than one question related to my take on capital-A Agile as a movement.  I plan on answering these questions directly, but I have opined on this subject a bit in the past:

Reading the questions I received and letting them kick around in my head a bit as I was jogging earlier today, I started to think obliquely about the topic and how it’s approached and regarded in the industry.  What’s going to follow is fairly raw riffing on this topic, and please forgive me if I seem a little loopy.  It’s about 1:30 AM, I just got back from a concert, and, given that I’ll be off the grid for a couple of weeks starting September 5th, I didn’t want to let a Friday lapse sans post.

1 Agilius

So, story time.  What would you think if I laid the following narrative on you?

17 well known, well respected elders from different villages came to realize that the prevailing methods for tending and cultivating crops were not sufficient to feed the growing populations of their villages.  These elders had some ideas, both mystical and practical, for how to solve that problem.  They’d gained much knowledge on their own and needed to spread the word.

They decided to convene a summit, but the odds were stacked against them.  Each village had its own ways of doing things and cultural preferences, and the elders were each accustomed to those around deferring to them.  Initially, they could not even agree on a location for the summit!  How were they ever going to agree on providing food for the known world?

Against all odds, however, they made progress.  They retreated into the mountains and toiled for 2 days and 2 nights, expecting little to come out of the gathering, but when the sun rose on the 3rd morning, not only had they made strides — they’d all agreed, as if by Divine Providence.  What emerged from this gathering were stone tablets containing the 4 Core Values and the 12 Principles of food cultivation.

Over the years, the Word spread far and wide.  What started as 17 quickly became dozens, and eventually hundreds, thousands, and hundreds of thousands.  Great centers of learning and cultural exchange emerged, devotees made annual pilgrimages to important sites, and the new methods for food cultivation spread far and wide.  And, lo, it was good.  There was much rejoicing.

In case this doesn’t ring a bell with you off the cuff, it’s basically the history of the Agile Manifesto.  And, before you bristle, read that history that I linked.  It says epistle in there to describe one of the communications between signatories, for goodness sake — if that doesn’t invite religious comparisons, I don’t know what does.  Try googling that word and finding a reference in the top 10 that doesn’t prominently mention the Bible.

Guru

This post isn’t actually about comparing capital-A Agile to religion.  This is well trod ground, and a well placed google search will let you tread it to your heart’s content.  But if you temporarily accept the premise as axiomatic, there’s an interesting plank to the agile canon that’s generally missing from religion, at least in my experience with it.  What I’m talking about is self-reference in a way that isn’t begging the question.   Read More