A large portion of my career has been spent fighting against organizational disarray. Over the years, I’ve become very accustomed to being dropped into an established culture with the intent and promise of doing everything I could to improve it in some way. Sometimes I was alone, and sometimes I was even accompanied by my closest friends and colleagues. While I’ve both succeeded and failed to varying degrees in both situations — and occasionally, even, at the same time — one thing has not changed: this is not an easy task. We were cucumbers, being dropped into jars with the intent to somehow, against the forces of nature, un-pickle pickles.
A few years back, I interviewed a woman for a Java software engineering position, and noticed that she had “extensive experience with Hibernate” on her résumé. I remember thinking to myself, “well, what an odd thing to mention having ‘extensive experience’ with. This person must really adore Hibernate.” I mean, it’s not like she put “has extensive experience building applications using Test-Driven Development,” or “has extensive experience modeling transactional domains.” Nope, “extensive experience” with a very specific framework devoted to a very specific task. Great. Let’s talk about that, I guess.
Not a lot of companies do Agile well. I know some very smart people who think Agile is an utter hoax — a gimmick, used to make buckets of money by selling snake oil to gullible organizations that are just struggling to stay relevant. I don’t think it’s because Agile hasn’t been effectively evangelized. I certainly don’t think it’s because there is some fatal flaw with Agile methodologies that makes them abstruse or impractical. I think it’s because switching to Agile is painful, and people are opposed to pain.
It’s Monday morning, and you walk up to your desk, cubicle, office, whatever, and set your things down. You open up your laptop or wake up your computer, take a sip of your $4.00 coffee, and look around the floor. Wait… something isn’t right. You notice 6 people you’ve never before seen huddled together with laptops. They’re drawing on whiteboards and pointing and arguing and laughing. Well now, don’t they just seem right at fucking home? Something’s not right, here — you can feel it. Relax. It’s much worse than you think.
Ok. Your team is backed into a corner. You know what the right decision is — technical or political — but are, presumably, adamantly disagreed with in your organization. In spite of knowing what you’re in for, you want to take a stand. You need to do two things, quickly and effectively. First, you need to credentialize yourself in front of everyone involved at the same time. Second, you need to focus on the contrasting effect each decision will have on the company, both in the immediate future and in the long term.
So your organization isn’t responding to reason. What started out as a team that would attempt to exemplify the way your organization wanted to do product development has become a micro-managed monstrosity, full of stakeholders, and absent of accountability. You’ve decided that in the face of this blame-storm you keep hearing referred to as a “team effort” (which you’re starting to believe!), you have to take a stand. Here’s what you’re in for:
One of my most visible faults early on in my career (and something I still struggle with to this day) was my tendency to rigidly represent my own (or my team’s) interests, regardless of how large or small. I say rigidly, because I would tend to hold the same position in spite of the political or emotional erosion to external relationships that might be caused. In short, I didn’t really give a damn about any external team’s preferences — I knew what my team wanted, and that was that. Over the years, I’ve learned that this is not the best way to do business.
There is a trend with my posts about software design where I write a lot about how it is a creative process. This is largely because for years, software design was considered to be busy work, and I take extreme issue with that philosophy. I find producing consistently effective software designs to be a very difficult task, and I deeply respect those who are good at it. I also find that those who are good at it have in common that they are all inspired workers.
One of the most common points of extreme contention I find between Agile and Waterfall practitioners involves a heated debate about the appropriate time in the project’s life cycle to be making important decisions about the software’s architecture. In one corner, we have the Waterfall approach of Big Design Up Front (BDUF), and in the other corner we have the Agile approach of Emergent Design. I’d like to outline some of the key differences between the two design philosophies because I think the right choice becomes obvious when they’re contrasted appropriately.
Speed and quality are universally contentious. Engineers always choose quality, but claim to value speed. Business owners always choose speed, but claim to value quality. Each side is skeptical of the other’s intentions when their actions seem to contradict their claims. Why does such an ironic and contentious relationship exist between the funder and the implementer? This post is not a referendum on either side: it’s a bi-directional concession letter, between Competent Business Owner and Competent Engineer.
One of the most difficult challenges I face in my professional life is is maintaining a healthy working relationship with people who I believe are deeply incompetent. Incompetency is, for me, extremely difficult to stomach — far more difficult than, say, laziness or apathy, because whereas those might point to an attitude problem, incompetency reveals that the basic skills necessary to effectively perform daily tasks are missing. To further exacerbate the issue, one of my [many] personal character flaws is that I find it extremely difficult to relate to or to support someone I do not respect. Because of this, I’ve not only become acutely aware of the truth behind the Peter Principle, but I’ve also picked up on an even more dangerous corollary that’s become more and more prevalent in the workplace. For the sake of discussion, I’ll refer to it as the Napier Principle.
While on site at a client the other day, I heard one of the FTEs make the statement about their brand new legacy application that “there was too much technical debt, so it needed to be rewritten”. I cringed a little bit, but I considered that I was just being pedantic, and decided not to nit-pick at the misuse of the term “technical debt”. Looking back, I’m not sure I should have let that statement go. I probably should have shed light on the important distinction that should be made between accruing technical debt and creating a mess.
“So, hey, you’ve got that report ready for review at 4 o’clock, right?”
“So, uh…I thought I had until Monday for that…”
“‘SO-A?’? No, not on SOA, on ‘World Domination and All Things Evil.’”
“So…no, I said, ‘so, uh‘…”
“…So…I don’t really know what you’re saying to me, but if you could have that report ready by 4, it would be great…”
What do you suppose the average person thinks of when they hear the words “software engineer”? Perhaps they think of a famous (or infamous) entrepreneur who’s been forcing them to restart their PC for years. They might even think of a hip, well-built hacker with an earring who assembles software “worms” by racing to reconstruct some antagonistic digital Rubik’s Cube1. But I would bet that the majority of the population would think of a middle-aged man with high blood pressure and vitamin D deficiency. Well folks, I’m here to tell you that while that last group may have been right for years, the Age of Milton is over.
I have a predictable threshold for Macy’s. Not too long ago, I was shopping there with a girl — which is to say that she was shopping, and I was serving dual life-sentences back-to-back for a crime I didn’t commit. The likeliest explanation for my unjust, albeit fashionable, incarceration was that she was a heartless shrew who had no concern for my long-term psychological or emotional well-being. In the unlikely event, however, that she was not pure evil, but merely that the allure of fragrances and cosmetics had acutely undermined her ability to feel specific empathy for the opposite sex — the scents having temporarily transmuted her into a sort of sociopathic shopaholic — I felt it would be in my best interest to point out that not only was Macy’s not where I would like to spend 84 hours of a Saturday afternoon, but also that it was utterly absurd to spend $1.4M — which is only a slight exaggeration — on eye shadow.
In 2005, socioeconomic researchers at Harvard, in conjunction with the local police force, performed a social experiment in Lowell, Massachusetts. After identifying over 30 of the highest crime rate areas in Lowell, the police forces were instructed to clean up litter from the roads and sidewalks, replace broken street lights, and implement a series of other small “cleanup” initiatives for 15 of the 30 areas. In the other 15, the police were instructed to continue operating normally. The result was an almost immediate 20% drop in police calls in the cleaned up areas. This is an interesting case-study for Broken Windows Theory.
Software engineers have an uncommonly difficult job. Not only are they tasked with the monumental challenge of accurately modeling a business in digital interactions, they also need to be constantly permuting the different ways they could be solving their problems and the pros and cons of each possible implementations. To make matters more difficult, they’re having to constantly juggle the ever-evolving needs of the client and an employer who thinks having something done yesterday is still late. You’d think that with all of this, we’d find little time to resist the progressive development philosophies and methodologies that have proven themselves for years from entrenching themselves in our day to day lives.
It’s a well known fact among software professionals that the moment your friends and family discover your technical competency, you will become their indentured technical support servant for life. Whether it’s re-installing Windows or replacing ink cartridges, no task is too demeaning: if it involves a computer, you’re the first phone call they make. And why not? This is your fault, after all.
A regular critique I hear of engineers who are new to projects or codebases is that they provide almost immediate negative feedback about what they see, and are in no position to do so. The feedback tends to be received as being premature, unsolicited, and out of context, and is therefore undesired. To further complicate things, the engineer typically genuinely wants to improve things, and isn’t merely interested in bitching. I’ve personally received this feedback multiple times, and frankly, I’ve had just about enough of it. Rather than meet this constructive criticism with hostility, I’d like to propose a different approach for the receivers of the feedback. I’d also like to offer a peaceful compromise.
Let’s briefly take a step back. Yes, we’re all very concerned with how best to drive software development. We love our methodologies and our philosophies — our little software calendar platitudes and acronyms. We love Martin Fowler, Kent Beck, Eric Evans, Bob Martin, so on and so forth. But really, what is the point? This article is for everyone who has ever been subjected to my ongoing ramblings and critiques of software, processes, and team dynamics. I’d like to try to offer you a moment — if ever so brief — of catharsis. These were my intentions. Here was my point.
In Working Effectively With Legacy Code, Michael Feathers defines “legacy code” as code without tests. I love this definition for two reasons: first, it provides a succinct, objective way to measure whether code is legacy or not; secondly — and this really is the main reason I love it — it asserts that any code, written by anyone, at any time, without accompanying tests, is legacy the moment it’s written.
The 2000 Presidential Election was mired in controversy over which candidate received the popular vote. Whether due to faulty hardware, or a state-wide psychomotor-disfunction epidemic, a large number of Florida ballots were unclear about which candidate they endorsed. “How could something as parochial and deterministic as aggregating multiple choice answers lead to such a quagmire?”, you might ask, and indeed, it makes for an entertaining story.
The Boy Scouts of America have a rule, “Always leave the campground cleaner than you found it.” I was never a Boy Scout, but I found out about this rule when I read Bob Martin’s Clean Code. I thought it was such a splendid philosophy to apply to software engineering and codebases that I’ve probably referenced it a hundred times. Sure, it rolls off the tongue nicely, and teaches children to clean up after themselves, but I knew there was something subtle about it that I liked that wasn’t immediately apparent — something more fundamental, revolving around diligence, discipline, and dedication. It occurred to me that the underlying philosophy I was so attracted to was this revolutionary concept of giving a shit.
There’s a skill that I’ve rarely seen among recent college grads walking into enterprise codebases, and that’s maintaining legacy code. It must be shocking to expect to walk off campus and on to a green field project, only to be met with a “where the hell did these 1.5 million lines of code come from?” sentiment. I’ve observed three particularly difficult challenges that less-experienced engineers face when working with legacy codebases: rapid understanding, adapting design, and finally, implementing bug-free modifications.
I have a few a stories I’ve told over the years to explain my origins in software engineering. One of the more humorous ones is that I wrote down on a piece of paper “Doctor, Lawyer, Software Engineer”, and chose the one that didn’t legally require a college degree. While that story is actually true, the reason Software Engineer ended up on the paper to begin with was that I had an instant, lasting attraction to the notion of being able to model real world interactions for the cost of electricity. Potentially even more than that was the allure of creating something out of nothing.
Terrorism comes in many forms. It’s commonly typified by leveraging hostage situations to undermine national policy and to facilitate foreign influence, or personal ulterior motives. An increasingly common incarnation of what I consider to be corporate terrorism manifests itself as so-called “knowledge anchors”: employees who have been with a company long enough to have acquired intimate knowledge about the business’ problem domain, and have subsequently outlasted any one else who might also have acquired the knowledge.
Here’s a scenario: two women are at Starbucks, talking about how their respective weeks have been. One woman pauses, then exclaims, “I’m just so excited about parenthood! I can’t stop thinking about whether it’s going to be a girl or a boy!” “Oh my gosh! Are you pregnant?!”, the other woman responds, understandably shocked, given that her friend has yet to show any signs of a pregnancy. “Well, not completely. I’ve never really been sold on the whole pregnancy process – you know, the mood swings, the cravings, the added weight. It’s not really right for me; I’m just interested in the ‘having a child’ part. I guess you could say I’m mostly pregnant.”
I’ve never received a compliment for making something simple seem complex. I’ve never had a conversation that began “Hey John, I think you’re great, as evidenced by the fact that I never know how the $@%# to begin attempting to use your code!” That would, of course, be absurd. Yet, for the longest time, I rarely thought about my fellow engineers when designing my solutions that they would, inevitably, one day maintain — or refactor.
It’s extremely difficult to find talented software engineers — especially in today’s market. I have my own theories as to why that is, ranging from the fact that software engineering is still a relatively young profession, all the way to deeper philosophies about how competent people are at their jobs, in general. What’s more, companies that lack talented engineers typically have a very difficult time finding talented engineers, and this is not coincidental.
You need a plan. You’ve just been told by your boss that the highly visible, habitually failing flagship project – yep, the one that’s a year behind schedule – just became your problem. “Don’t worry, you can only come out of this looking good,” you hear, among other things, like “hand-picked” and “Swat Team” – each one making you cringe more than the last. You’ve been here before, and while the stakes may be different, one thing is certain – You. Are. Fucked.
The people who know me best are rarely shocked when I take a new job. After all, I work in a highly volatile industry, and it’s never long before something potentially more enticing than my current situation shows itself. I like to think this is true for everyone, with the possible difference being that I tend to react to these new opportunities, whereas many people do not.