This was always as absurd in reality as it sounds metaphorically, but unfortunately, not always as obvious. Neil has written about this a couple times. This is actually the reason I’ve worked at 7 companies in 5 years. The problem is that the longer you stay around pickles, the more you get pickled yourself. You start getting accustomed to a weekly onslaught of production defects, and code that only occasionally works. You get used to managers that hide behind PMPs because they don’t actually encourage personal and professional growth. You get used to being surrounded by uninspiring pickles, and it’s starting to affect your outlook.

My friend, we have enough pickles. We have enough people who think engineers are a cost of doing business, and paid to code, not think. Find another jar — a better jar, with other cucumbers, and don’t lose your passion and ambition for what you do. Don’t get used to broken process, and don’t be okay with poor software quality. There are other cucumbers out there, and we can help. Find us. Just don’t get pickled.

No, as it turns out, as I’ve been in that situation a few times and failed to do so. To sacrifice yourself for the sake of your company is probably something that died out in the 1950′s, and I have no evidence that people even did it back then. I would be surprised if it did occur, as sacrificing oneself for the greater good, goes against human nature. Instead, I would continue to be the problem, and I would continue to collect a paycheck. I have to say, I’m ashamed of myself for doing so. Now, I suppose I can sleep at night, as I did take my concerns to my superior every time I was in a situation where I was doing more harm that good. In both instances (yes, there were two) my boss reassured me that I was doing the right thing. Not coincidentally, both of these bosses ended up being dismissed withing 6 months of my departure. I suppose the lesson learned here is that if you think you’re a part of the problem, listen to your gut and not your boss.

Now that I’m old and wise (NOTE: I am neither), looking back, I could have simply written a resignation letter to the effect of, “For whatever reason, my employment here isn’t working out. It may be you, it may be me, or a combination, but the end result is the same — I do not belong here.” Looking at myself as a 3rd party, I would have respected that — an employee self-evaluating that they’re are a bad fit for a company, and choosing to bow-out rather than be shown the door, and/or take their bosses and co-workers down with them. Fact is, I didn’t have that courage in the past, and instead, convinced myself that my boss’s reassurances that I was doing the right thing was the truth, though I knew in my heart that it wasn’t. If I became faced with the same situation today, I hope that I would have the courage to resign for the sake of the company and co-workers. Perhaps it’s old fashioned to think this way, but when it’s all said and done, all we are is who we look at in the mirror, and I’d like to think that doing the right thing never goes out of fashion.

I wish I had a clever anecdote that neatly sums up how you can be (and stay) technical but also lead, but I don’t have one. In my experience, you either go all-in on technical, or go all-in on lead, or you do a disservice to your team. If you’re a technical lead, and go all-in on being technical, the code will stay well factored with little technical debt, you’ll personally solve the most intractable problems, and bail the project out when it’s behind and some hero coding is called for. If you go all-in leading, scope will stay under control, deadlines with be reasonable, estimates will be done well, and the general level of chaos will be reduced to a minimum.

I tried really hard to be both technical as well as lead, but I failed. Miserably. Repeatedly. After my last failure, I decided instead of trying to be both, I would go all-in on one of them. Since going all-in on leading drives your career to middle management, I decided to go all-in technical. I couldn’t be happier. Sure, scope is out of control, estimates are sh*t, deadlines are unreasonable, and the general level of chaos is off the charts, but at least the team gets someone who at least does one thing well — being technical. As an added bonus, there’s a lot less stress in tackling technical problems than arguing requirements, scope, and deadlines. Will I ever try my hand again at the “lead” part? Only time will tell, but for right now, I’m enjoying the sweet life.

So¹ I said to her, ”talk to me about ORM”. She stuttered a bit, and shook her head, signaling to me that she was in the dark. “Oh, um?… Object-Relational Mapping…?” Still nothing. ”Wait. What? OK, wait. You have ‘extensive experience with Hibernate’ listed on your resume?” “Oh, yeah…” she said, as if she finally got the joke. “Hey, listen, can I tell you something?” My interest was piqued.

“So², look, my recruiter told me to put that on there. I’ve actually never used Hibernate, but [the shit-eating recruiter] said when people ask for ‘Hibernate experience’, they typically mean ‘Spring experience’”. So many things immediately went through my head, but I was too shocked and amused to be livid. I couldn’t help but laugh. “OK, interesting. (I’ve never heard someone ask for Hibernate experience, meaning Spring experience, but moving on…), but, OK so you have Spring experience then?” “Oh. Uh, no.” True story.

<sup>1. I don’t mind it here.
2. Fucking sucks here.</sup>

But that is part of the problem, isn’t it?  Processes that were defined by others, and have since lost meaning and/or relevance to the people [attempting to] adhering to them and resources being applied toward performance metrics, perhaps without regard to the actual quality of the product delivered.  That is the fundamental challenge of MBO and without the right kind of leadership in place, it is a disaster waiting to happen.  Or if it’s already happened, it’s a death-march spiral without end.  As I watched this unfold in my own project, I know the solution required a different approach.

Instead of focusing on metrics, I turned my attention to improvements first.  Whether this was a proper approach… well, that’s for someone else to determine.  Make small and immediate improvements first, to get us out of the death spiral.  Then, and only then, do the other de rigueur kick in.  Until there is improvement to the current situation, any amount of planning, definition, standardization and/or management — perhaps most importantly — won’t yield realizable results.  Then and maybe only then, would looking at the performance indicators make sense.  Because then, it would actually mean something.

Well look, you can get into a huff if you want to, but if you’ll calm down a moment, I’ll explain. First, it’s your personality — it annoys the sh*t out of me. Shut the f*ck up, focus, and lets get some work done. Don’t get me wrong, I’m all about keeping things light, but jokes have to in the context of getting work done. I don’t want to hear a knock-knock joke your 3 year old daughter told you this morning that has absof*ckinglootly nothing to do with figuring out the best way to test this method. Keep your eye on the prize; this is work — not play. While you’re at it, keep your attitude in check. Here’s a tip: say it once, it’s venting; say it more than once, it’s whining.

Second, you and I don’t see eye-to-eye when it comes to the discipline of software engineering. I take this sh*t very seriously. I’ve worked extremely hard to get the knowledge that I have, at great personal sacrifice, and for as much as I know, there is still vast amounts that I do not. I worked my ass off to get here — seems like you just got lucky. You wouldn’t know what an object was if it was sticking out of your ass. You think layering is something you do to keep warm in the winter. You are f*cking clueless and a waste of my time. So no, I’m not going to pair with you. Instead, I’m going to pair with that guy, and we’re going to get some sh*t done. You? How about you go get us some coffee, catch up your personal email, and leave us the hell alone.

A great book I read early in my career was “The Effective Executive” by Peter Drucker, who many consider to be the father of modern management. In the book, he draws a clear distinction for how the modern manager was going to have to learn how to manage “Knowledge Workers“, as management techniques that worked for Factory Workers were not applicable. He used the analogy of laying bricks: If you spend more hours laying bricks, you will lay more bricks per day, and will therefore be more productive. Knowledge workers, on the other hand, are not more productive the more hours they work — in fact quite the contrary.

Instead, he put an emphasis on something else: Effectiveness. Are we getting the right things done, and in the right order? Rather than look at a metric that is easy to measure but irrelevant (hours), look at something that is difficult to measure, but extremely relevant (work completed). Whether it’s XP, Scrum, Lean, Agile, Kanban, or whatever the trendy label of the day is, it has the same intention: 1) What are the important things that need to get done, and 2) What is the order in which we need to do them. I used an important word there, but you might has missed it: DONE. Not started; not in progress; not finished yet to be tested; not tested but with bugs — DONE. Jimmy is busting his ass — sure he is — but is he getting the right things done, and in the right order? If he is, give Jimmy a pay increase and a spot bonus — he’s probably the most effective employee you have. I do worry about his home life though… hope he’s single with no kids.

Agile is painful because it affects your entire product development organization, not just one group — which means you can’t reasonably replace the ones who don’t “get” Agile with the ones who do. You would be starting over. Hell, you’re basically doing that anyway. If everyone’s productivity and comfortability in their roles instantly evaporates, and panic ensues, you’re not ready for Agile. If Product Owners throw temper tantrums and paper weights, and Engineers crumble under the pressure of iterative development, you’re not ready for Agile. If BAs laugh with cynicism and frustration at the notion of things like Minimum Viable Product, and QAs make PowerPoint presentations about why it’s unreasonable to expect any sort of quality or automation from “this so-called in-cycle testing thing”, listen to me! You. Are. Not. Ready. For. Agile. At best, you will end up being mostly Agile, which is to say not at all.

Short of hiring experienced (and deeply-concerned) consulting firms, these types of organizations will falter and fail in their attempts to succeed in implementing Agile, and it’s because they haven’t really read the fine print. They’ve been blinded by the allure of all that Agile practices give you, but they skimmed over the part where it talks about what a monstrous investment the switch will be. In fact, short of going out of business, switching to Agile is the largest and most disruptive type of change I’ve ever witnessed to happen to a company: even more so than an acquisition. It’s intensely painful, but these pains are always temporary for an organization. To the ones that give up and ultimately abandon Agile, they’ll be remembered as being paralyzing and insurmountable — a supposed testament to the impracticality of Agile principles. But to the ones that push through — well, they were merely growing pains.

I’m not a fan of the word “Agile”, as I feel that people have already formed their opinion of what Agile is, and generally I don’t agree with them. Instead, I prefer to speak about particular aspects of my interpretation of Agile. Regardless of your opinion on Agile, it’s hard to argue against the value of rapid iteration and continuous improvement. When you iterate rapidly you find design flaws and bugs quickly. When you continuously improve, you fix design flaws and bugs quickly. The result is what some call “chaos”, but I call it progress.

I like progress — a lot — but I wasn’t always this way. I mean, I would tell people I liked progress, and even believed that I did, but the reality was that I was so obsessed about producing high quality code with a low defect count that I forgot the point of software development — to develop software. What I have now realized is that to arrive at quality code, I have to iterate my way towards it in order to make incremental progress, which is more important to me than arbitrary point-in-time subjective assessment of quality. The path is crooked, and at times chaotic, but if you are backed up by a strong team fully bought in to rapid iteration and continuous improvement, then I highly recommend you give it a shot. Just don’t call it Agile.

Imagine if a service staff at the restaurant told you that the meal wasn’t up to par because of the silverware selected, or blamed the salad on some beets, or told you how the oven didn’t bake the your slice of pizza just right? Or if the chef came out and explained that because he read Chef Daily’s suggestion of sous-vide being the future of cooking and funny how that didn’t make for a juicy, crunchy and tasty fried chicken? Diners wouldn’t stand for it. No way. Yet, both as consumers and as technologists, routinely, we hear and accept the lines of reasoning excuse of shifting the burden onto the technology itself. You’ve heard it before. Maybe you’ve done it yourself. It’s because Java does this. It’s because the framework did that. QA forgot to check for sub-feature Z. If only we had chosen native instead of HTML5. It’s completely absurd, and I’m over it.

It’s time we hold each other and the industry accountable, to what we agreed to deliver. It’s time to stop reducing the standard of excellence, after commitments and engagements have already been made. It’s not easy and we hate to break up the buddy-buddy [b]romance, force a little personal discomfort and call each other out when so-called subject matter experts [ that's us, in the room ] make a mistake, or set the bar too low, or simply fail to deliver on execution. Good managers have to do this with their subordinates, and I’m saying that peers, as equals, have to do the same with each other. Think about, until we do that, there won’t be any real buy-in either because we’re willing to cut someone slack and accept sub-standard results. I don’t know about you, but I’m tired of rubbery tasteless fried chicken.

The people you are looking at are consultants, and you are about to be told by your manager that they’re here to clean up your mess. Your product and your hard work is being taken from you and given to outsiders, and there is absolutely nothing you can do about it. You try to argue with management and explain why it’s okay that your project is 8 months late — oops, the consultants wouldn’t be here if a deal wasn’t already signed. You threaten to leave. You’re told you’re allowed to. You feel sick, betrayed, angry, hurt, used. Your mind is racing. Slow down.

It occurs to you that you have not actually been terminated yet. In fact, the only person who mentioned the termination of your employment is you. You walk up to one of the consultants, determined to quickly and publicly prove their incompetency. Before you can utter a word, they look up and smile at you, genuinely. They warmly introduce themselves, and acknowledge your value on the team, mentioning that they’re looking forward to working with you. You believe them. They shake your hand, introduce themselves, and invite you into their huddle, where they’re discussing some of the most problematic parts of the codebase and which areas they’d like to address first. It’s as if they’re verbalizing all the problems you’ve had with the project that you were unable to articulate. You’ve never heard of ThoughtWorks before, but they seem like they might actually be able to help. Relax. It’s much better than you think.

Software engineers, when looked at through the lens of society as a whole, are comprised almost entirely of geeks and nerds. In high school, while jocks were out partying on a Friday night learning the subtle arts of speaking to women, these future software engineers were at home playing video games. When a jock was learning how to do the minimum to get by, the geek was lamenting over less-than-perfect grades. When jocks go to college, they are drawn to fraternities like ants to a sugar cube. Nerds, on the other hand, too busy with study to socialize, miss out on male bonding rituals, and instead seek to fill the void of brotherhood in their professional careers.

Software engineers are conditioned by the software development industry to think that they are defined by their programming language, and to switch programming languages is a dangerous act of disloyalty. Who will want to hire someone who has only worked professionally with language A, and now wants a job programming language B? Absurd. So much safer to stay in your comfort zone, rather than try to break ranks for no apparent gain. Besides, writing software in a particular programming language is really the point of software engineering. Starting over is hard, and there’s no reason to put yourself though that when you have already paid your dues. Take pride in being a [insert language here] programmer, and don’t be one of those people who pushes themselves outside of their comfort zone, only to suffer the consequences.

As it turns out, as if there weren’t enough vectors of attack already — SMTP, the web, SMS — we now must add NFC as the latest avenue of entry for those with malicious intent.  And more importantly, in addition to simply being a conduit, NFC is smart and may contain configuration or configuration-change type of payload [ an example is that NFC may be leverage to set up Bluetooth, or modify WiFi ] and couple that with the usual carelessness by software developers, lack of familiarity from being the new things, and general un-awareness because people simply do not consider security over ease of use… NFC may become a far scarier technology than the original intention.  Some people will clamor for SSL, somewhat mis-applying channel encryption and not realizing it simply takes away the opacity of the traffic, but not the problematic traffic itself.

All non-wired solutions suffer greatly from eavesdropping and leakage.  To some degree, even hard wires may be tapped, but any/all wireless transmission makes it a little easier to inject into the stream.  Now, a potential attack only needs to be close[r] — while standing in a line, perhaps, or sitting next to you on the train, in a theater… or simply pacing you as you walk through some type of controlled environment, and voila NFC brings the evil of the world to your door pocket.  Am I simply beating a dead horse and rattling off paranoia?  Sadly, no.  Within a few weeks, we will see some Real Life attacks, where malicious, targeted code will be pushed onto the NFC device, and then forced to execute and then ultimately compromise the NFC device itself.  Good thing it’s just a little ol’ NFC device… not like we keep money, access credentials, intimate details of our lives, or anything important on those things anyway.

Quick and effective credentialization is difficult, but here are some tips. First, know your sources: for instance, if you’re referencing software design, know names like Martin Fowler, Kent Beck, and Bob Martin. When you understand and can cite what the leaders in your industry believe, you’re leveraging effort that they’ve already spent to win battles that they’ve already won. It’s difficult to stand up and refute what the industry experts collectively believe and not look foolish, making this a fairly effective credentialization tactic. Another one, of course, is speaking about direct experience you might have had dealing with the particular challenges and struggles that your organization is experiencing, and how it went for you. Direct experience is not always available, but when it is, it’s potent. No one can really refute that what you’re saying is true if they weren’t there, can they? It also builds confidence that you’re a trustworthy source on whatever matter you tend to be fighting over, given that you’ve seen this before.

This one’s a little more difficult, because it tends to be regarded as highly subjective, even if you know it’s quantifiable: focusing on the impact that each decision will make on the company in the short and long term. The best advice I can give here is to pull from case-studies: when 5 out of the 6 Fortune 10 companies that attempted big-bang rewrites in 2012 abandoned them half-way through, and the 6th is facing another rewrite, that’s evidence. It may be incidental. It may even be refutable. But it is case-building and adds another line of defense. Talk impersonally about the forthcoming affect that each decision will have, so that the only side you’re representing is the side that’s best for the company. Speak eloquently, and formulate your responses carefully. Articulate your concerns. Leave it all on the table, and go update your résumé. The rest is out of your hands.

A series of wrong answers can be considered a strong indication that someone does not know what their talking about, but a single wrong answer can be just as damaging depending on your audience and the nature of the question. If the question is, “What is a computer” and the answer is, “It makes toast” (and they’re being serious) then it’s safe to say they know nothing about computers. If the question is, “When the JVM is running in a virtual machine on 16 core processor hardware with 4 threads running, how many more threads can a J2EE application create?” and you answer 9 – but 9 is the wrong answer, then what? What have you learned about that person’s ability? Nothing. Yet, that one wrong answer can cause someone to not get a job and/or lose the respect of their peers.

We need to assess people to know how to work with them, otherwise we run the risk of speaking over their heads or being condescending. However, we also need to temper our assessment of their answers, and look inwards to determine if the question itself was fair. Most often, an extremely difficult question is really asked so that the interrogator can feel better about themselves, as an insecure interviewer attempts to demonstrate their intellectual superiority. When you are asking a question, think about what it would be like if the tables were turned. If you think the situation would be fair, then by all means proceed. If, on the other hand, you feel as though punching the interviewer in the neck would be warranted, I urge you to reconsider. After all, you might end up working with this person.

Trusting each other, at a professional/work level, isn’t about some touch-y feel-y semantics. Trusting one another is also not about the predictible level of contribution, based on past experiences. That seems counter-intuitive, as most of us are used to thinking about trust in terms of someone doing good before, and therefore is likely to do good again. In fact, trusting in my fellow team members actually means that I am not afraid to be candid and honest, not just about my strengths but also my weakness, without the fear that somehow those deficiencies will be leveraged against me down the line. It also makes it possible for me to ask for help, without the concerns of penalty. It enables me to make mistakes, and recover from them.

It’s not easy trusting people, because we tend to view each other as competitors. In fact, professional achievements often rely on the fact that we’ve excelled and surpassed, those other individuals in the respective fields. However, that path only scales so far because one person cannot be good at everything and at some point, a team of people will absolutely outperform the one. That is why it’s crucial to be a part of a team, and a successful team starts out by trusting one another. It’s not an easy behavior to modify, but without trust, there will be no team. Of course, this must be a mutual move, or we are right back in competition, defending ourselves and killing each other. That is not how teams work. Not every group of people will be able to pull this off, but when it does happen, you’ll be amazed what could be accomplished.

First, things are going to get unpleasant. Most people dislike conflict, but everyone dislikes hearing they’re part of the problem. If you think people are displeased with your team’s performance now, just wait until they’re on the business end of an after-action review and their role isn’t in the “Things Done Well” quadrant. Second, you’re going to be scrutinized – and I mean under a microscope — and I don’t mean like in the way a botanist admires nature through the examination of a leaf; more like in the way a biochemical engineer watches bacterial cells, always on the lookout for indicators of any exploitable weaknesses. This one is particularly difficult to deal with the first time, as you’ll have to face the harsh reality that you might just be the only person in the equation who’s actually focused on improving the project, rather than advancing your own career by damaging someone else’s.

Finally — and there’s really no getting around this — you may lose. You may lose huge. You may ultimately be thought of as a cautionary tale for crossing Product, or Architecture, or Management-or-QA-or-whoever. For this reason, taking this kind of a stand should really only be done as a last resort — pretty much when things couldn’t reasonably get worse, and when you’re ready to leave if you must. Are you ready? Are you sure? Ok. Fight.

Often heard among progressive Agile practitioners is term “sustainable pace“, but I rarely hear a sufficient explanation as to why this is important. In short, thinking hard for long periods of time physically hurts. For those of us who think for a living, we either develop a tolerance for this pain, or we learn how to take breaks in order to let the pain subside – often both. Some of the most productive engineers have mastered this skill, applying a careful balance of work and leisure time. These engineers can seemingly produce high quality work day-in, day-out, with no signs of fatigue of slowing down. They are engineers that are working at a sustainable pace.

Project managers are typically lectured by engineers on sustainable pace, when asked to work overtime to hit a date. In order to teach a project manager sustainable pace, try the following: Give them an 8 hour long-answer test (as in, not multiple choice) every day for a week. It doesn’t matter what the test is on, so long as it requires intense brain work. As the end of the week, inform them that because the test is incomplete, or that some of the answers are wrong, or that new questions have been added, or that questions they have already answered have now changed, they will have to work the weekend to make up time, as well as work an extra 10 hours the next week. Keep this up until they understand sustainable pace.

One of my favorite quotes from the movie Knockaround Guys is when John Malkovich explains to Barry Pepper “Used to be, there was a way to do things and things got done [..] now everyone’s feelings are involved.” The truth is that many times in today’s business culture, it can be problematic to make the technically correct decision for the business because it might go against someone’s personal preference and therefore offend them,  making them difficult to work with later on. Negotiation might seem to be the answer when you disagree on implementation details, but even negotiation presents it’s own problems, mainly that neither party actually gets what they want, which can get very old after a while.

The best way answer I’ve come up with yet is simply concession. This goes against a lot of what I personally believe in, but really tends to be best deterrent I’ve found for hurt feelings. Certainly you shouldn’t become a door mat, conceding in every argument, or else you will have invalidated the point of conceding to begin with. But you also shouldn’t have to enter an “integration points” meeting preceded by a reputation of inflexibility and self-service. If you really want to keep your collaborators cooperative, don’t make everything a negotiation — occasionally cave.

Let’s face it, discipline isn’t natural, and more importantly, most of us crave ease in the form of less work. Perhaps less intuitively is that by doing specific preparatory work, we could actually reduce the required effort down the road — insert some parable about tortoise and the hare here — but most likely, the shortcut-seeking tendencies means that we won’t do the necessary prep and instead, opt to peddle faster/harder on the tailend to make up/pay later. Admit it, you’ve done that more than once, in your own professional life. Because why do today what you can put off for three weeks? Except despite hearing, and acknowledging, that hope is not a strategy, people continue to go through the same cycles, manually perform some specific tasks, secretly and wishfully hoping, that the outcome would be different this time. It won’t be.

As our roles overlap, blend and generally approach one another — ops toward developer, and vice versa, we should remove ourselves and our well-intentioned but ill-fated tendencies from the equation through automation. Anything you do more than twice, consider automation. Testing shouldn’t be a manual effort. Configuration management shouldn’t be a manual effort. Deployment shouldn’t be a manual effort. Is this supposed to be eliminating jobs? Absolutely… unless your job is supposed to be pushing buttons every a light flashes. No, companies can hire monkeys for that role… your job — our jobs — is supposed to be solve problems creatively. Whether that is Agile or DevOps, time to get on-board.

In the rare times someone asks me to describe myself, I have thought of describing myself as a “Professional Mistake Maker.” It’s true — that’s what I do for a living. I never try things that are in my comfort zone. Never. I find them dreadfully boring. My God, who wants to do again something you already know how to do well? It’s like getting another gold medal for a race you know you’re going to win. After 100 races, who cares anymore? It’s so much more stimulating to come in last to a race you thought you could win, only to find out you have a lot more to learn. And really, this is the root cause of mistakes: a desire to learn.

Making mistakes is an art form. It’s a beautiful dance of failure, and one whose bittersweet sting I’ve come to enjoy. Failing is simply a strong indicator that, perhaps, I need to change my approach. Failing completely and utterly (which I’ve done several times) means only that I need to change directions. If there is one piece of advice a sage Professional Mistake Maker can give you it’s this: Acknowledge your mistake, learn from it, pick yourself up, and try again. Keep that up for a decade or so and you will be what other people refer to as experienced, but more importantly, you will have a sense of life accomplishment that those who stayed in the comfort zone will never know.

For me, inspiration is absolutely critical to effectively designing elegant software, and for that reason, I place a high level of importance on my ability to consistently find inspiration. Of course, this can, at times, be nearly impossible. Maybe I’m having a bad day, or I’m distracted because of other things happening in my life that are taking psychological priority. Who knows — maybe I’m just burned out. The net effect is the same: in these mindsets, I am an ineffective engineer. That does not mean that I can’t complete user stories or fix bugs in this mindset. I still retain the intellectual ability to come up with a solution, but it probably won’t be on you want to maintain. This is an important distinction that I think could use a lot more recognition in our industry: an uninspired engineer is an ineffective engineer. If this is true, then an engineer who is regularly uninspired has a big problem on their hands.

If you’re like me, you should constantly be evaluating whether you’re in an adequately inspired state of mind to be able to design elegant solutions to your problems. If you’re finding it difficult to articulate your solution, get up from your computer. Read a book, or look into the distance and take a breather. Get something to drink and listen to some music. Do your best to take your mind completely off of software in general. This is an extremely important trait of consistently effective engineers: knowing how to maximize the amount of time that they’re inspired, and knowing how to walk the fuck away when they’re not.

I have been accused a few times of being “intense”, and it’s probably a label that I deserve. I love my line of work, and attack it like something I’m deeply passionate about. However, that passion can come across like a stream of scaling hot water shooting out of a fire hose (phrasing?). No matter the topic, if I’m asked a tough question about a tough problem, you’re going to have to strap in for a bumpy ride (phrasing!). Knowing this, I always try my best to lighten the mood either before or after my onslaught, as I know that people can get hurt, and little pain relief goes a long way when the pressure is starting to mount (phrasing!!!).

There are people who let their stress fester, and it leaks out in strange and unexpected ways. Perhaps it’s a question that comes across more as an accusation, or an email with a harsh tone, or “Come to Jesus” meeting for a trivial issue. When you see the tell-tale sights of stress, be the class clown. Anything that will cause people to chuckle, giggle or belly laugh will do. If you’re no comedian, give this a try: Next time there’s a pause in a tense conversation try a “Ain’t this a b**ch” or in your most melodramatic tone, “So, it has come to this.” You might just be making someones day, and if you do it consistently enough, saving the project.

A less aggressive version of this is already happening in the fertile eco-system of smart phone apps. Combining social shopping drivers (time limited coupons or pop-up deals), QR scanning and other location-specifying check in functions, now more than ever, retailers have an expanded electronic reach toward their customers. Not satisfied with analyzing past opt-in data, more and more retailers are moving toward capturing all the transient traffic, especially people who are not and by process, opted out of being part of the purchasing demographic. With the proliferation of mobile devices — mobile sensors, practically — at all age groups, there’s never been a richer or more in-depth glimpse of the individual consumer profile than now, by those seeking this information.  It’s getting difficult to see where sampling ends and Orwellian Big Brother begins.

Maybe the retailers are right. Maybe by knowing everything about me, my life would be better served and my needs anticipated and somehow I have save more time and well, effort. Maybe. Because so many people (the so called masses) completely, willingly perhaps unknowingly, offers all that up without hesitation, all of my efforts (not being saved) at remaining anonymous, not glows neon-bright like the anti-pattern that it is. And that pegs me into a hole as well. Of course, all of this is supposed to done with my authorization and consent.  The only true opt-out appears to be turning off my phone.  However, who does that in this always-on/always-connected world we live in?  It may be paranoia, but I cannot shake the feeling that someone is watching me. Even if it’s for my own well being.

Big Design Up Front is exactly what it sounds like: a series of protracted deep-dives into a perceived holistic view of the application. I say “perceived holistic view” because this view assumes that the impressions the BAs and the Architects have of the project before it’s been built are all correct and immutable. Of course, the major drawback to BDUF (and Waterfall, in fact) is that this assumption not only tends to be incorrect with extreme consistency, but is also regularly invalidated very early on in the project’s life cycle. This is primarily due to the facts that first, humans are fallible and miss requirements or design accommodations; and second, projects evolve very quickly.

Emergent Design is very much to the contrary of BDUF: it is a series of design decisions made out of necessity, rather than supposition. It is design at the last responsible moment: the moment after information has been collected to give appropriate context to a problem, but before it’s too late to backtrack without reasonably expensive changes. Emergent Design balances strategic design decisions based largely on implicit requirements with tactical design decisions based largely on immediate needs. It assumes refactoring happens every day, and that the optimum design is approached successively, rather than modeled up front.  I know it’s tempting to do BDUF — you think you’ve got it all figured out, and you want to see an intelligent design come to fruition. Trust me on this: resist the urge. You’ll never know less about the optimum design than you do right now.

Software engineers are the most fickle type of whiny prima donna out there. If you put the average pop starlet up against the average software engineer, I think you’d find they list of demands right on par in terms of being unreasonable. “I have to have a Mac” and “I like the lights to be dim” and “I need to work from home” are pretty average demands for a software engineer — and God help you if you don’t give them what they want. They will pout, stamp their feet, and throw tantrums. However, much like an upset child, it’s most often not just the individual that’s the problem, but the environment they’re in. They simply need to find a job that better suits them.

Finding the right job is a critical skill for any software engineer. When you start looking for one, you fret about how you will do in an interview. Once you find a company you like, you fret about how they will do in the interview. Nothing is more devastating than being in an interview with your dream company only to find out you’re in a room full of idiots – or worse, arrogant idiots. When an engineer hasn’t found the right job, they will be a holy terror, causing devastation in their wake. If you are such an engineer, take a good look at yourself, and ask yourself if you need to switch jobs. If you employ such an engineer, fire them. Don’t worry, it’s not so bad.

Most of that distinction centers around the devices themselves — screen resolution, rendering, native code vs HTML5, etc — things related to UI or frontend development.  On the back-end or server side, it may not matter what type of client is being serviced, be it web application or mobile application.  In this always-connected world, developers are growing up without memories, and the lessons learned, of a time when latency, bandwidth and topology often did break the application.  The luxury of not knowing that time period, when speed is measured in bps instead of Mbps, is reflected in the design and performance of these applications.  They are wasteful in consuming bandwidth; they remain largely un-informed regarding network security; the hidden cost of transport is readily passed onto the users themselves; and avoiding bottlenecks happens after the launch, and then sudden success breaks the application itself — to the point we’ve coined terms for it, FailWhale, slashdotted, to just name a few.

It’s not that ideas like social or image-centric applications weren’t dreamt of prior to this current state of mobile application.  However, resource constraints meant that creative solutions were applied elsewhere.  It simply seems like currently, developers are producing apps, even useful ones, without consideration that mobile devices may travel in and out of range, cross network (much less, national) boundaries and there may be cost/penalties levied against the user in a heavy data model.  Why?  Because broadband, DSL, Ethernet and WiFI have created this myopic vision of the world.  I’d like for apps to continue to maintain reasonable functionality when the signal is weak.  I’d like for apps to be mindful of my battery and data consumption.  I certainly have no interest in paying for roaming charges — a scenario much more common outside of North America — unnecessarily by dormant programs.  But none of those seems to be top of mind in this generation of mobile apps, and instead, as a user I’m left to fend for myself.  Can you hear me, creators of products and solutions?

Dear Competent Business Owner: To an engineer, speaking about speed is speaking idiomatically about the fastest responsible pace, which is to say the fastest pace at which acceptable quality can be achieved. When you demand shorter timelines, we perceive that you are undermining our judgment about how long acceptable quality should take — which, by the way, you are, in fact, doing. Negotiate with us, and work with us to understand why we’re taking longer than you would like.

Dear Competent Engineer: Respect the fact that when speaking about code complexity and time lines, you are in an unfair position of leverage, similar to the position an auto-mechanic is in, explaining to a suburban house-wife why an $80 oil change turned into a $600 repair. Abuse this position at the expense of all of our collective credibility. Work with the business owner to explain that your job is mentally taxing, and your synapses need time to fire. Explain that to rush would be to rob them blind in maintenance cost and future feature additions. Negotiate with them, and work to understand why they need you to occasionally cut corners.

Regardless of your background, skill set and the environment, the fundamentals of the challenges, of the situation remains the same. It may be that you’re brought on-board for a new effort (growth), or to replace someone, either doing a good job (maintenance) or doing a bad job (rescue), there is a transition period where you will have the least amount of knowledge, despite of whatever other hard skills you bring to the table. More importantly, there will be a lot of focus/emphasis because you’re often the visual representation of the change itself. Momentarily, it may seem like one of the three — growth, maintenance, rescue — may have an advantage over another, but ultimately, you’d want to excel in any one specific, as long as you’re aware of the challenges going into the new setting.

I won’t bother with the specific strategies, as there are no two situation that’s exactly alike. But a similar approach may be adopted at addressing all scenarios, regardless of origin — and to some degree — or the challenge itself. Learn quickly. Examine the problems you’re asked to solve quickly, and pick the right strategy for attack. Garner some quick wins, however small. And if you make mistakes, make them smaller and make them more quickly. Build those relationships with the stakeholders, and make sure the technology and the technical solutions show sufficient alignment to the business itself. As you cultivate those relationships, measure them in the level of reciprocal support, because you’ll need them down the road, when things get really tough. And did I mention do everything as fast as possible? It’s not rocket science, but it will require some effort and a clear vision and sharp, critical thinking. It’s a piece of cake, as long as you can catch your breath.  The clock is ticking, why are you still sitting there, just reading?

“I’m not sure how to answer,” I reply calmly, shifting my body language to show that I am relaxed, yet ready for battle. The facilitator is caught off guard — never has a commoner dared to express a lack of certainty in response to a direct demand for delivery date. “Why not?” they reply gruffly, unable to mask their frustration. Looking distant and aloof, I move another piece into position: “I don’t have enough information to know how much work is ahead of me.” Infuriated by this apparent recrimination, they chortle “What information do you need?” I respond with, “I don’t know yet, but should in the next few hours”. Bishop takes queen-side rook. Check.

Stunned and confused, your opponent breaks out into a cold sweat, struggling to identify their next move. How can they now ask for a direct answer without appearing overbearing — or worse yet — disconnected from the realities of actually doing work? Surely there must be a way out, but every second that ticks away erodes their authority. In an ill-advised and clumsy maneuver, they let fly what they hope to be a killing stroke: “So can I have your answer by end of day?” With a rakish grin, my overarching strategy is finally revealed, too late to be thwarted: “That depends on how long this meeting takes.” Chuckles are heard throughout the room. Checkmate.

The Peter Principle stipulates that the phenomenon of systemic incompetency in the workplace can be attributed to a fundamental flaw in corporate advancement strategy. That is, if employees are promoted based on their successes, they will naturally tend to rise to their level of incompetence, or to the point where they cease to succeed. While this is concerning, I’ve noticed a growing trend where companies attempt to promote employees out of their level of incompetence.

This, to me, is both far more disconcerting, and absolutely absurd, because with the Peter Principle, promotions cease at an employee’s level of incompetency; but with the Napier Principle, that’s exactly where they start! Don’t believe me? What about that one middle-manager at your company who used to be an engineer, but was terrible at it, and thus promoted to be kept away from the codebase? Somehow, their inability to perform their task effectively lead to a leadership role over others who could. Watch out for this: it is cancer to an organization. Run from this type of company, unless you’ve been hired to address this type of problem. All the Napier Principle leads to is a disconnect between the manager and the employee, and resentment. Oh, and more incompetency.

For one thing, I had gotten rusty at interviewing.  Not because I haven’t had to apply for one position or another over time, but because I had selectively favored companies whose audience already favored what it is that I do. I hadn’t needed to walk into a cold room, as there often is an insider recommendation easing my application for employment.  This time, it was different.  Or the same.  I had just forgotten.  I’m back at the catch-22 of starting out — wanting a position without the exact experience required, and wanting the experience without some prior qualified position — remember that period of your life?  Luckily, my fellow feyn-mates worked with me on re-activating and exercising those dormant muscles of selling my highlights to the prospective (hiring) audience.  As engineers, we are not foreign to the concept of sales.  I don’t just mean working with the sales team down the hall.  Or vendors who routinely pitch us one type of wares or another.  We ourselves participate in selling daily, even if we’re not fully cognizant of the act.

We are selling, when people accept the solution we’ve proposed.  We are selling, when people adopt the practices we’ve been espousing.  We sell to our bosses on time lines and deliverables.  We sell to business stakeholders, even if it’s fraught with negotiated terms.  We sell to one another in the team, in dividing up the tasks or assignments.  For those of us who manage people, we sell the motivation for achieving corporate goals, occasionally.  And of course, at the end of the day, we sell to our customers by reminding them how the product meets their needs.  It may not always be slick brochures and rib eye lunches, or extolling past accomplishments and regaling perspective employers with an engaging narration — those things definitely help, incidentally — but as professional engineers, we just happen to be able to take the next step past selling sketches on a napkin.  We do more than pitch.  We can build it.

Under extreme performance conditions, a well designed application will just grind to a halt and stop honoring requests, rather than puke and collapse into an unrecoverable state. This is actually not an easy thing to design, as it requires quite a bit of art to pull off. Within the industry, people don’t talk about this evil little place where the application runs out of system resources as electrons and silicon fight for air in a rapidly drying pool of capacitance. No, we like to ignore this and say stupid things to make ourselves try to forget that the inevitable is just an DDOS attack away.

Bad things will happen. Your poor application will one day leave the nest and and take its place in the cloud. On that day, it will no longer have you to protect it by increasing the heap size of your local app server or closing your email because you’re running out of RAM. It will be in a deployment environment outside of your control for an indefinite period of time, and its only defense against falling over in the face of dwindling resources is what you give it when you’re building it. If it makes you feel any better, most engineers don’t give a sh*t about this, and just let it fall over, but then again most engineers are lazy bastards.

Technical debt is the result of an engineer being faced with the choice of the appropriate design decision at the time, or some other favorable outcome (usually short-term), and consciously deciding to go with the latter. Accruing technical debt is intentional, like using a credit card. It’s a decision to get a result without contributing the effort necessary to earn the result, but always with the intention of paying it down. Just like with credit, if the debtor is good at managing their technical finances, they should be able to easily avoid falling into overwhelming debt, usually resulting in having to negotiate with bill collectors (management) and occasionally resulting in declaring bankruptcy (a rewrite).

A mess, on the other hand, is an unmitigated river of a bad decisions devoid of any discernible amount of discretion. It is bad decision making without rhyme or reason, and is typically perpetuated by engineers who have no context or frame of reference by which to measure a good design decision over a poor one. Messes are extremely dangerous, because they point to a competency or professionalism problem, and almost always result in a rewrite, the scale of which is proportional to how intricately the mess has been woven into the fabric fibers of the application. Look at your code, and focus on the parts that disturb you. Check the author’s other commits. Make sure they were intentional and temporary, and hopefully annotated with a TODO. Otherwise, you might find yourself declaring bankruptcy on behalf of someone else’s mistakes.

The challenge is that, automation does not reduce errors like some magical fairy dust.  People have rallied around it without realizing some the side effects, especially when the starting points of so many automated tasks may be severely flawed to begin with.  Automation will not clean up your mess, and more importantly, it absolutely removes some of the safety controls that were once present in the manual and belabored efforts.  The elimination of small and frequent interactive human touches – where the same small and frequent errors are injected – means that now, one singular mistake may be replicated through the whole and the magnitude of such a singular mistake is magnified many folds.  Fewer small problems, but boy, the one problem will likely be HUGE.  Automation’s strength aligns with speed, scale and cost reduction.  “Doing it wrong” is a human mistake, and not a weakness of automation.  The computer is literal, it is doing exactly as you commanded it to. As a tool, automation must be used to increase coverage, like in QA, and not for simple laziness, believing that the tools will manage themselves.

The duality of being great at engineering is that there is absolutely no recognition — sometimes, not even a nod from the direction of the software team themselves — on achieving a spectacular milestone. However, the Spanish Inquisition will assuredly arrive to find facts on behalf of the management team if things ever go awry. The level of ensuing finger-pointing is directly proportional to the level of publicity such a going-astray commands. Remember, by that time, it’s not really about identifying causality as much as channeling the embarrassment or anger onto some deflective path, as to avoid the painful introspection [ or revelation ] on what truly went wrong. Identifying human errors takes effort, gumption and a heaping bowl of humility. The easier out is to un-shoulder the responsibility onto systems and processes — oh especially automation — because that’s surely where the mistakes were made.  If it was up to me, I’d still double-down on automation.  The alternative is not the answer.

Being drafted into leadership sucks. One day, you’re minding your own business, trying to do the best job you know how, and then someone taps you on the shoulder and asks you to take on a formal leadership role. The though is this: You’ve displayed an innate leadership ability (probably without trying) and if they give you an official title, you’ll be all the more effective. It’s hard to think of a more destructive thing. The reason you are (soon to be were) an effective leader is that you were, “one of us” – someone who worked with us in the trenches, and therefore had a pulse on what was really going on. As soon as you are promoted, you instantly become “one of them”. Furthermore, what used to come naturally to you now has to be forced through a sieve of “appropriate conduct”, further eroding any respect you may have garnered by working shoulder to shoulder with your peers. Instead of grinding away day-by-day buried in the suck, you’re away in some pointless meeting. Instead of being able to say, “That guy’s an incompetent [flip]“, you have to say, “He has an opportunity for improvement”. You’re neutered. You lost your mojo. And it’s not coming back.

Then there’s the thing that always gets me: Leadership – in corporate culture – sucks. They’re not leaders. They’re out for themselves, and to make themselves look good so they can climb to the next rung. Don’t talk to me about the exceptions, I’m talking about the rule. Once you become “one of them” you can’t go back to being “one of us” – there isn’t a reverse career path. Therefore, you have to claw and climb up the food chain because there is no place left to go but up. How do you rise in an organization? By putting yourself second to the needs of the team? In fantasy-wonderland maybe, but in the real world you follow the laws of power, and do what has to be done to outshine the next guy. Why? You have no choice – you’re a “leader” now. Don’t you have ambition? You don’t want to be a middle manager your whole life, do you? Besides, the higher your rise, the greater your ability to address broader organizational concerns, right? Keep telling yourself that. What’s the solution? Quit your job, and get hired on as a grunt somewhere else to re-boot your career. Either that, or settle in to spending the next decade of your life desperately clinging to the hope that one day you might be the next VP in charge of whatever, only to find out that your past loyalty to the troops hinders your ability to rise by stepping on them.

This type of conversations absolutely drives me up the fucking wall. I hear it in one form or another multiple times a day, and only after actually taking the time to write it down did it finally occur to me what was so intolerable about this type of weak speech: it’s the word “so”. Somehow — and I’m not sure when this happened — “so” became the staple of passive-aggressive prose in the workplace, preceding any statements that the speaker might foresee as being potentially disruptive or ill-received. For some reason, people think that it’s a diffusing technique. When I hear it, I instantly — possibly subconsciously, even — label the speaker as preeminently defensive and ineffectively manipulative.

Stop pussy-footing around your point. Worried you’ll lose your job for what you’re about to say? Hire a communication coach to teach you how to effectively articulate your point while maintaining an open, honest, direct and respectful approach. Still worried about losing your job? Find another one! Don’t waste your time in an environment where your perspectives will be discouraged unless you can dilute them with weak, indirect language. Seriously, avoid saying “so” as much as possible, and when you’re tempted to, ask yourself why. While it may seem to keep tempers down in the workplace and buy you a little time to write your reports, it comes across as if you’re either trying to mask your incompetence or stall while you think of an answer the person wants to hear. Either way, it’s not good. Don’t do it anymore, okay?

When you sign on with a company, there’s a document you sign called your employment agreement. Give that a read. If it says you are required to work a 50 hour work week, and you signed it to get your job, stop reading as this article doesn’t apply to you. However, if you’re like to majority of us, it probably assumes a 40 hour work week, which is most likely explicitly called out in the employee handbook. What this “40 hour work week” implies, however, is largely lost on people working in software development. It doesn’t imply that you come in at 9:15am, take an hour for lunch, and then leave at 4:45pm so that you can dodge traffic. No, it’s saying that you owe them 40 hours of business value. When you do the math, that’s more like you arriving at 8:00am and leaving at 5:00pm with a 1 hour lunch break, or working 9-to-5 but skipping a lunch break. That’s what they’re paying you for, but you abuse the system and end up giving them around 6.5 hours a day. They get pissed, and try to balance the equation by pressuring you to work more hours.

Then, there’s the quality of the hours you do give them. Let say you are one of the few employees in software development who give their employer a solid 8 hours a day of business value. What did you do during those 8 hours? Did you goof off in the break room? Did you attending a mind-numbing meeting where you spent most of your time paying bills online? Are you giving them the business value they’re paying you for? What I’m driving at here is that we [ collectively ] need to stop bitching about being asked to work overtime UNTIL we start giving them the solid 8 hours they pay us for. At that point, when they want us to work the weekend we can legitimately put our foot down and politely decline. What happens next will hopefully be a discussion acknowledging the difference between a knowledge worker and a factory worker. Then again, we could always unionize.

It’s easy to blast the decision makers for not embracing the wonderful world of tablets, and phones and other cool, nifty toys in this mobile space.  However, that’s just it… more than a few of the mobile innovations are still just toys.  Admit it, most of the popular apps fall in the infotainment curve, and is of little productive value.  Do people consider investment returns prior to purchasing that iPad?  How does it improve the household bottom line in leveraging mobile?  More importantly, I wonder how many purchase decision was simply made – on a credit card no less – without consideration of expenditure and debt.  It’s really just a cost center, without even the slightest appearance of generating revenue.  The office cannot be quite as un-restrained as readily-swayed impulse shoppers in a mall.  As much as we may crave some of those comforts, the work place isn’t about the consumer experience.

You’re not supposed to be playing Words With Friends, Draw Something or practice photo-journalism.  Taking a break from the keyboard, was never supposed to be surfing for the daily-LOL on YouTube.  The employment agreement, in exchange for a paycheck, surprisingly does not mention Facebook and stringently require that “work” be performed during the work day.  Who knew?  Additionally, most people probably do not practice enough safe computing in protecting their (personal) information, treat malware prevention as an after-thought, and heck, if you lose the phone, just go and purchase another one.  Can you imagine working at a place with those kinds of cavalier approaches to asset, security management and business practices?  No?  Some day, when the apps catch up and there is a proper model for securing devices and generating returns, mobile may be the only platform in the enterprise.  Until then, get back to your desk already.  Five o’clock is still hours away.

In the late eighties, software engineering was largely comprised of building back-office applications from white cubicle farms with fluorescent lighting. Nowadays, the profession has a sort of excitement and exhilaration behind it, primarily due to the nature of the products that are now being built: Facebook, the Curiosity, and Tony Stark’s car are all the product of modern software engineering. This profession which used to exile its implementers to dark corners of an office is now embracing, through methodologies like Agile, open and ongoing dialogue with them.

This can be extremely difficult if the engineer is a poor communicator or socially inept. The most effective engineers in today’s market are not only exceptional craftsmen, but are also great verbal communicators. It’s interesting to consider the correlation between communicating effectively with code and communicating effectively in conversation. Personally, I find the former to be significantly easier, and for a few reasons: first, you have time to gather your thoughts; second, you can assert and validate theories before you socialize them; third, you can refine your phrasing. In conversation, however, you must do all of that in real time, while also attempting to keep a compelling tone and cadence to your speech and constantly reacting to nonverbal queues. Ineffective communication from an engineer is no longer an option. We aren’t line workers; we are knowledge workers — it’s time for us to learn to articulate like some.

^{1. Please, like you know what the fuck he’s doing either.}

The programming practices of the modern software engineer are amazingly diverse. They include Object Oriented Design, Functional Programming, Design Patterns, System Architecture, Software Frameworks, and Test Driven Development. Each of these practices all have the same goal: To reduce the total number of lines of code. Some would argue in the short term, several of these practices will temporarily increase the number of lines of code e.g. a Strategy pattern where a switch might do, or a Domain Model where a God Class would suffice. However, in the long term, each result in a net reduction of lines of code thanks to a judicious application of the DRY principle. Learning the proper application of these diverse, complex, and at times paradoxical practices is a career long pursuit, and is a skill set typically only found in the most experienced of engineers. To say it another way, the very best engineers are working their hardest to reduce the total number of lines of code.

Think of the number of lines of code like straws in the proverbial haystack in which one seeks a needle. The primary measure of developer productivity is their ability to rapidly locate needles in the haystack. The more straws, the harder it is to find the needle. “Finding the needle”, in this context, is what a developer does when they program: They scan through many thousands of lines of code looking for the proper spot to change or enhance in order to incorporate a new business requirement. The secondary measure of developer productivity is their ability to apply the change or enhancement rapidly with little fear or breaking the system as a whole. Both measures are dramatically impacted by the number of lines of code, with productivity spiking upwards sharply in small code bases, and plummeting when the code base becomes massive. This is the #1 reason developer’s overwhelmingly prefer working in green field projects rather than in legacy systems. What then is the proper method for gauging a developers productivity? Simply put: Business value added per unit time. Agile methodologies provide a means to measure this type of productivity in terms of the team’s velocity, which is derived from user stories (business value) completed per iteration (unit time). If you cannot gauge productivity from velocity, and instead feel compelled to glance at the number of lines of code, there is strong possibility that you are doing Agile all wrong.

As I’ve stated, while both Apple and Amazon were exploited by the attackers, can you imagine a consumer world without the conveniences offered by both companies?  Imagine if you had to key in credit card numbers, every single purchase?  Once upon a time, that was the practice, and people griped and likely demanded storing of their credit cards.  So it came to be.  Or needing to work with customer service in resetting account credentials and having to actual go through deep-dive vetting, as opposed to the PIN method?  How do I know, because people are lazy and carefree about that kind of behavior, until it jumps up and bite them.  Don’t believe me?  Think about how many people write their PIN on the ATM cards… don’t pretend that scenario does not happen.  Ease wins over security, almost all the time.  So now, suddenly, it’s Apple’s and Amazon’s fault that the convenience they offered is exploited.  Sure, some processes got subverted and what was a feature now became a huge risk, but that’s what happens when intention and design are not fully aligned — or at least not fully considered.  The moment any personal information is put out onto the web, you have already accepted the risk that information may be subject to misuse.

Then the part of not backing up, except into “one” cloud.  One cloud is better than a drive array of one’s own making, but imagine a company only backing up business critical information one time via one device.  That solution would be laughed and rejected out of the room so fast, yet in our personal lives, people are a lot more cavalier about the value of personal information.  LinkedIn’s breach is going to cost them millions of dollars, what is the worth for pictures of Zoe as a baby, or the simple sense of well-being and privacy?  What’s more shocking is the shock that there are hackers who aren’t even looking for a financial gain necessarily, but acting destructive wanton purely for entertainment value — to amuse themselves and pass the time.  I’ve seen that movie before, the one called rm -rf / because if the attack isn’t successful moving forward, let’s make sure there’s no traces left behind. In case I haven’t written the word back up enough, make sure adequate back up exists, because who knows what may happen to the data even if it were hackers erasing drives.  Backups are for expecting the un-expected.  That is all.  Harnessing technology is clearly a Promethean effort, let’s make sure hands are not burned in the process.

To be a good QA – and not want to physically harm yourself – you have to write automated tests. You have to code to test code. If you hate coding, and therefore hate writing automated tests, then you’re going to hate your life as you endlessly click the same button, seeing it do the same thing, and checking off the same list for the umpteenth time that it still goes, “Confirmed!” every time you click it. When you were a kid and someone asked you what you wanted to be when your grew up, testing confirmation pop-ups was your dream? Hell no. That’s not the job you want. Automate that crap so a machine clicks that button for you. That way, the only button you click is the one that says, “Run Automated Tests”.

Engineers look down on QA. OMG, yes, I said it. If you haven’t figured that out by now, then you haven’t been paying attention. I assure you, the elitism is far worse than you could imagine. I’ve heard engineers say things about QA that would make you want to punch a baby. The way to turn the tide is simple: Write code that tests their code. You will make their life a living hell. Engineers make mistakes – lots of mistakes. They’re allowed to get away with it because their mistakes can be so subtle it can sneak past a manual QA tester who can’t possibly test everything. When you have your automated tests, however, nothing can get past them – and if they do you can simply improve the tests such that next time they can’t. At that point, your full time job is pwning elitist engineers, and while it may not compare to being a rock star or movie god I will tell you, it does feel good.

People rarely get to work in ideal environments, where the balance of team members, tools, and requirements hum in a harmonious unison, while immaculate products are made and delivered.  In the real world, set backs are routine and conflicts arise regularly — anything that may potentially throw a wrench, often will.  Overcoming these challenges is what sets one apart from another.  Whether a company, a product, or an engineering team has any longevity comes down to serving some kind of need. Acting and reacting too slowly, and you may miss the window of opportunity.  Not listening, and not understanding the plight of the user, will drive that very business away looking for a different, better, solution.  In this competitive market place, there is no place for arrogance or assumption because there will always be alternatives.  Technology evolve, things change and if you, your team or your organization behaves like a woolly Mammoth… don’t be surprised when a single innovative caveman armed with a crude axe whacks you on the head.

The exaggeration is for emphasis, because we all know it takes three cavemen to successfully tackle the beast.  Meanwhile, there are no perfect launch windows for the MSL.  There was an opportunity and then there’s the attention to details, to focus on what needs to be done and planning for the resiliency.  It took team work, discipline, and probably million lines of code — of automation — to ensure the successful launch and landing of a space vessel.  Comparatively, some of our daily tasks may be more mundane than going to space, but upon successful execution and completion of the goal, it’s still a sense of pride and accomplishment.  Get your ass to Mars already.

As you might imagine, this was an unfortunate strategy. In retrospect, I would have arrived at a much more desirable outcome if I had mentioned that I was getting hungry and that the myriad of overpowering fragrances were starting to give me a headache. The problem was that I made an impersonal and non-relatable case. This is also a mistake I make all too often when attempting to persuade organizations to change their ways. Too many times I’m stoic instead of understanding; calculating instead of concerned. I’ve grown accustomed to using words like “absurd” when describing an organization’s 18 minute, non-deterministic build process.

You know what the truth is? It is fucking absurd. Many times, the ridiculous challenges organizations are plagued with have no earthly business being problems in 2012, and it tends to be extremely difficult for me to relate to them. However, I’m not there to write a dissertation on all the ways they’ve misunderstood encapsulation, and I’m not there to win a debate about Java’s terrible inheritance model: I’m there to improve a situation. As a general rule, whenever I’ve made this mistake in the past, I would have been far better off had I taken the sympathetic approach. Maybe instead of explaining that a 1500 line POM file is atrocious, I could instead sit down and listen to the sordid tale of how the organization ended up with 53 unused dependency entries, among other perversions. Maybe I could mention how these types of challenges are really tough when you don’t have an exhaustive and comprehensive understanding of the tools you’re using. And maybe next time I won’t mention that, by the way, that’s the information they hide in books.

It is up to the savvy Ops engineer to recognize this particularly flawed impetus.  Furthermore, the irony is that it’s far easier to not do something stupid, than it is to actual do something smart.  Because doing something smart requires effort — awareness, common sense and applying the right solution to the right problem, etc.  At this point, if you’re wondering how to determine if you fall into the smart and competent camp, vs the less smart and probably unqualified camp, you are already ahead of the game — because only those people who care about their soul, have a one.  Remember, competition between vendors is ruthless, and it’s not chance happenstance that an army of sales people strapped with slick pitches, back nine passes and other enticing items find the weakest link in the decision tree and attack it with using the enterprise wine-and-dine maneuvers.  Objective assessment do not come from that direction.  Real life war stories come from fellow survivors on the frontline.  Trust someone with hands-on experience, and because you’ve surrounded yourself with competent peers, draw upon that collective wisdom to combat the impulse to act simply because.

Of course, this is not an advocacy for monolithic stonewalling of service delivery.  This is certainly not a battle cry against early adoption, rapid deployments or the ideas of iterative improvements.  All of those and other best practices are still true and should be respected as such, where applicable.  The is just a reminder to pause, however briefly, to think about the basic task of evaluation and decision making, and to make sure that before you, or someone else, commit to a course of action, it isn’t the result of reactive, short-attention span jitter swayed by the wrong influences.  At the end of the day, support is tough enough without self-inflicted dumbness.  When you push that button to go and go forward, make sure the smart decision is pushing the button at all.

What the police force found was that by addressing a series of little things, you can effect a cumulative impact that’s more significant than the sum of its parts. In fact, one of the foundational premises of the original article on the topic was that large problems like vandalism and crime are the causal result of allowing small problems to fester. Thus, by fixing problems when they’re small, you can prevent larger problems from ever occurring, for significantly less effort. I’ve written about how to apply this to a codebase, but I believe the generalized theory holds some interesting premises for team dynamics and organizational efficacy as it pertains to addressing the early symptoms of a system that’s trending badly.

The symptoms start small, which is largely the point. Twenty-minute standups can be one symptom, and can ultimately lead to a de-emphasis on internally managed accountability, resulting in external micro-management. Specialization among pairs could be another, which can create communication silos and erode team-wide communication. One of us is currently struggling with meeting overload, which can ultimately lead to a myriad of unhealthy organizational challenges. In comparison, these problems are significantly easier to address before they snowball. For instance, if someone feels especially articulate in a standup and is having trouble staying on point, it’s not unreasonable to politely interject that they’re getting off track and their story, while certainly fascinating, is a better topic for coffee-room conversation. In-team cliques can be discouraged from forming by encouraging promiscuous pairing and open communication in dev huddles. You can even reduce structured meetings by holding ad-hoc group conversations regularly with your team members and facilitating open, honest, direct, and respectful communication. Take my word for it: address the little things when they’re small. You wouldn’t believe how quickly an organization will fall to disarray if you let them get away with the small things.

Getting fired for what you believe in is still getting fired, and it stings just the same. When we’re kids we’re taught (or should have been taught) to do what is right, and some of us bring doing what is right into our professional careers. The problem is, doing what is right doesn’t always line up with doing what you’re told. “Right” is a difficult thing to pin down, as it is based on nothing but your subjective assessment of the situation. If you disagree with your employer, and refuse to do what your told, they’re well within their right to fire you. And really, if they do, you shouldn’t be totally shocked. They were paying you to do what they tell you, and not what you felt like doing. If you choose to stop doing what you’re told to, why should they keep paying you, and presto! You’re fired.

Is there any honor in getting fired for sticking to your personal beliefs and doing what is right? Yes, there is. If you refused to cook the books to save a couple million in tax liabilities, then hold your head high. If you refused to tell your team they have to cancel their Christmas vacation to hit an arbitrary project deadline, then be proud of yourself. If you committed yourself to doing what was in the best interest of the customers, even if it wasn’t in the best interest of your boss, then good for you. When it’s all said and done, your life isn’t going to be defined by a single job, it will be weighed in it’s entirety, and history looks fondly on those who stay true to their convictions. Still, if you’re setting yourself up to be a martyr, make sure that you have an updated resume and a couple of months of cash to float you, as bill collectors are unmoved by excuses from the moral high ground.

Not too long ago I was with a new colleague that I’ve come to amass a significant amount of respect for. In the presence of other fellow trusted technologists, we heard something rather alarming – their team had made the conscious decision to not practice test-driven development. “Certainly there must be more to this,” we thought, and proceeded to probe a bit. It became quickly apparent that there was no deeper truth to discover — the team was comprised of engineers who had intentionally opted out of TDD in order to code faster. This was extremely disheartening to both of us, and after a moment of disbelief and frustration, my colleague exclaimed “I thought we had polio beaten!”

Why in the hell are we still arguing about this? We have bigger fish to fry. I understand if you’ve never done TDD and as such are hesitant about your short-term throughput. Spoiler alert: it’s not going to be great, especially if you don’t have someone on your team who has strong experience with it. But that doesn’t change the fact that opting out of it really shouldn’t be an option. This comes down to professionalism, and with all the commotion of rapidly changing requirements juxtaposed against building quality in at the ground level, there’s little time to be resistant to the progressive methodologies (from the past) that have finally started taking root. It’s time for some solidarity among engineers – we have tough jobs, let’s not make it tougher on each other by fighting against things like TDD.

But of course, your organization does not do this. No, you hire for exceptional talent, and encourage your employees to think outside the box in order to come up with creative solutions to difficult problems. Sadly, this is a lie you are telling yourself. Exceptional talent is very expensive, and seldom on the job market because, well, they are exceptional. You punish employees for thinking outside the box, because they will be fostering change, and change is disruptive, and disruption is the antithesis of a smoothly running organization. At best, you offer the banal complement of, “Good idea” and encourage them to document the idea for future consideration. At worst, you fire them for not focusing on their core job responsibilities, and therefore not meeting company expectations. Little thought is given to what the now ex-employee was attempting to fix, or why they were attempting to fix it. All too often, the employee was not focusing on their core job responsibility because they realized that in order for the organization as a whole to improve, they must attempt to address an issue orthogonal to their set job expectations. They do this because they want to focus on their core job responsible, but are unable to do so until the issue is resolved.

What makes exceptional talent exceptional? How did they get that way? Excelling at standardized education? A rote following of the rules handed to them? A focus on unwavering day-in-day-out steadiness of measurable progress? Not in the slightest. These exceptional individuals (that you now find yourself unable to attract) were once rebels within their organization, breaking free of the limits of their job description. They took risks, made mistakes, got in trouble, and kept going, and occasionally got fired. Now, when you look at them you believe them to be magical, as they so dramatically exceed expectations. They are not magical – they have simply broken out of the finely tuned corporate drone factory. By definition, this is what makes them exceptional. The question then remains, are they exceptionally good, or exceptionally bad? Not coincidentally, it takes an exceptional middle manager to tell the difference.

The list of victims of implicit permit is long and sordid, and can be easily traced back to a time predating the so-called modern web, back when consideration of security did not play a role in application development.  History buffs may remember the jokes about Sendmail, with each passing week a new bug would be exposed.  Or the packet filters [ that eventually became firewalls ] that permitted everything, and rules were written to exceptionally deny.  The problem in both cases is a faulty approach… the rules should’ve always been explicitly permit and implicitly deny, because as creator of these software and logic, one should already know [ in advance ] what is permitted and within bounds of execution.  Sendmail shouldn’t have unplanned passing of parameters.  Firewalls shouldn’t allow packet traversal unless it was known and expected.  Yet in each case, programmers blacklisted unexpected behavior only after each successful breach, repeatedly.  It took many weeks/months/years before explicitly permit and implicitly deny became the default for both programs.  In hindsight, that seems crazy.

Yet that is exactly what is happened, and apparently happening, with SQL injection attacks — the careless and negligent handling of input data, and then additionally passing it onward into a database without limiting access [ or other ] permissions.  This implicit permit problem continues today and elimination does not likely in the near term.  Already, the next-generation of OWASP Top 10 reads like a bad re-run, as the rise of mobile applications have led to an equal rise in intrusions based on untrusted input.  Let me repeat that, input is not to be trusted.  We’ve seen this movie.  We know the ending.  We know how to slay this particular dragon, and it’s not implicit trust or permission.  It takes nominal more effort to implement the right solution — to explicity permit and implicity deny.  Do it already, so that we may go back to writing other, original, insecure code instead.

Instead of saying, “Dude, that is the most [flipped] up [poo] that I have ever seen in my entire [gosh darn] career.” I have to say, “Ah, OK. I can see opportunity for improvement here, here, and here. Also, here, and here. And here. Perhaps we can pair up together for a refactoring?” Man, look, I don’t want to pair with you – I’m just saying that to be polite. You have to know I’m being polite. You saw my face twitch when you showed me the 40th method on your 700 line class. You heard my voice crack as I choked out my thinly veiled stream of [bull poo]. You know full well I want to curse you out for being a [dumb bell] in front of your peers, but can’t or else I’ll get fired.

I’m not going to justify my need to curse. Blame it on a poor education that failed to give me an adequately sophisticated vocabulary with which to express myself. I really could give a flying [flip] as to the justification. The fact is, with a curse, you can know exactly where I stand instantly. That saves the company time and money – which is nothing but a good thing. Think of the openness, honesty, and directness that “Your code is all [flipped] up” conveys? [Heck], I’m not even trying to offend you – I’m just calling it like it is. If we can get past this childish notion of not cursing in workplace we can focus on things that matter – like the proper usage of the various inflections of [flip].

The first time you spoke about defragmenting a hard drive you doomed yourself. They have a new printer, and you know what CMYK stands for: their problem is now your problem, and this is the way the world works. This happens all the time in corporations, only with significantly higher risk, and significantly more challenging logistical problems. For instance, if you verbalize to a manager that a team’s iteration retrospectives could be more fruitful if they made actionable items a priority for the things that went poorly, you will have just become the owner of the team’s retrospectives – complete with all the hassle of facilitation, minutes recording, and follow up. Why did you say anything at all? Don’t tell me you were just trying to help — no one’s going to believe that you’re that naïve.

It feels good to sound smart and capable, and it’s nice to be able to answer questions with enthusiasm and helpful contextual back stories. It does not, however, feel good to end up owning a problem that you have no interest in owning merely because you were too cavalier with what you knew and who was within earshot of what you said. And don’t expect to refuse ownership once the cat’s out of the bag — that’s not what a team player would do! In fact, that would be uncooperative! And…and selfish! Seriously, if you don’t want to own the problem, don’t run the risk of sounding competent. And the rest of us — I guess we’re just gluttons for punishment.

When the world first moved from dial-up to broadband, the initial generation of users suffered every imaginable offenses, before the firewall appliances and the anti-malware solutions came along. That was with a smaller and slower adoption, and not everyone left their desktop turned on and plugged in.  With laptops and Wi-Fi, things got worse, again, until security and Web-consciousness caught up in the form of encryption, certificates and passwords.  Social taught and continues to teach the hard lessons on information privacy.  Now, with this wave of mobile — covering the gamut from smart phones, to tablets, to home and lifestyle devices — the opportunity for complexity, and exploitation, has never been greater.  The same platform and resources for developing fantastic and useful code may also be leveraged for previously un-imaginable, versatile and powerful botnets.  When is the last time you turned your phone off?  When is the last time you checked the un-seen software running within the smart O/S, behind a visually stunning display?  Are you even able to peek behind the curtains?

Blaming the consumer culture is no help. People are lazy and will always choose ease of use over security.  But that’s “regular” people — layman who does not understand authentication from authorization.  We are not those people. As providers of this double-edged sword, we must be the diligent curators, the watchful guardians and the last line of defense against those who seek to exploit the mobile universe. Do not write crappy code.  Be security conscious. Do not escalate privileges un-necessarily, and do not dip into more data than you need — avoid those temptations, because trust me, the bad guys will come knocking. Let’s not make it any easier, because the web is full of ready-to-plunder scenarios, and we’ve gone through this lesson plan, at least twice, already.

For the rest of this article, let’s assume “engineer” is “employee”, because while this is common with engineers, it’s not unique to engineers. Consider an employee who has no context about a company’s past, but evaluates a situation at face value. I would argue that their evaluation is not only extremely useful, but also it could potentially point out problems that veterans at the company may not notice due to countless other distractions. They may even be problems that were at one time obvious, but have since been accepted as the “way things are”, or too difficult for anyone to fix. The veterans who adopt this attitude are suffering from Stockholm Syndrome.

The employees that are bold enough to point out problems early on in their employment aren’t going to be satisfied with the statement that “this is just the way things are”. That statement will be interpreted as a defeatist attitude, and the employee will have no use for that. It will also seriously undermine the credibility of the person who says it in the employee’s eyes — as well it should. Don’t ever say that to us. Instead, provide context as to why things are the way they are currently, and why no one has successfully changed things yet. Here’s the compromise: we’ll take a softer approach with our feedback, if the veterans will  acknowledge that it’s not okay to merely leave things the way they are. Remember what it was like to have to do whatever fucked up thing we’re critiquing back when you had to do it — maybe this time around we can help propose a better solution.

Exit planning isn’t just for entrepreneur’s looking to cash out from their ideas. Or looking for the next opportunity in your career ladder. I won’t waste any explanation on why exit planning is the panacea to deployments gone awry, disaster recovery and business continuance. More importantly, exit planning should cover the adoption of any technology — let’s face it, whatever clever toolset or powerful framework or even the web language du jour will one day remind you of Perl. Or Shockwave. You get the idea. The people who wrote billion lines of COBOL that drove banking industries probably never imagined that those same lines of code would still be around in 1999 and cause the eventual End-Of-World Y2K problems. Conversely, knowing how to get away from the smarter mouse trap isn’t just about updating and upgrading. It also means the ability to evaluate and determine the time and path to upgrade/update [which is just another variation of exit], without being forced to upgrade or update, just because the vendor is looking to up the licensing revenue. By knowing how to get out of the situation, before you get in, the dominoes are better managed.

This isn’t a call for meticulous waterfall of decision making and planning. The future cannot be controlled like that. Just the opposite. Attempting to satisfy on that global level of planning is destined for failure. This is actually about being agile and being incremental, because doing so decreases the likelihood of monolithic decisions that will erect sudden albeit slow walls on all sides and leaving the hapless managers, engineers and developers trapped in the middle. Make good [smart] decisions. Leverage standards. Adopt best practices. All of these will ensure your safety, whether you’re on an airplane, jumping out of a burning building, or just wrangling code. You know there will be an ending, so know how to get out and move onward, without being prompted by emergencies. Don’t get in, unless you know your way out.

Try this the next time you’re enjoying an overpriced cup of cow secretions and burnt bean dishwater: Take out your phone, turn on the video camera feature, and position it such that it can record someone’s (or many people’s) keyboard, hands, and screen. Then just leave it there and record while you read your morning paper. After that you just [editor redacted to safeguard the innocent]. See? It’s that easy. No matter how many boards, bricks and chains you put up, it just took a camera phone in a coffee shop to walk through the front door.

Freaked out yet? That wasn’t even that hard. As a matter of fact, you’re probably going to try it the first chance you get. In many ways, that’s a good thing, so that you can convince yourself that you need to defend against something this simple. “OMG how???” you ask. There’s lots of ways, and they all suck. For this you really want IP address white-listing. Sadly, most applications can’t get away with IP white-listing, so you might try IP blacklisting, which is a lot like protecting your house by surrounding it completely with land mines (hope you never have to leave to get more cow secretions). Now you come to the horrid realization that there are some attacks you can’t rationally defend against. Give up? Nah. It’s like chess – giving up is the only guaranteed way to lose. They moved camera phone to coffee shop, what’s your move?

When you understand TDD, you realize that it’s actually extremely compelling if you want to facilitate rapid changes to a codebase while ensuring that quality is built into the product, rather than added retroactively later. When you start to understand the advantages of pair programming, you realize the distribution of domain knowledge and understanding on a daily basis is beneficial to the product. When we debate design patterns and evaluate code on the basis of the S.O.L.I.D. principles, it’s because an object having one responsibility leads to simpler designs that are easier to use to recompose into new features, rather than duplicate concepts, which reduces effort in maintaining and extending the product.

Are you seeing a trend? It’s about the product. Nothing — not good architecture, not clean code, not unit tests or test-driven development, not Agile practices, not pair programming, not domain-driven design, not adaptive software — I mean, none of it is important if it doesn’t facilitate a quality product, faster. That’s it. That was the point. All of the critiques and conversations about how to build software better is about how to implement a strong vision rapidly with acceptably high quality. So you can make money. So we can have jobs. So people can have better lives. This is, and has always been, about building the product. Anyone who cares about any of this for another reason should not be trusted, because they have some other priority than simply building a great product quickly. Neil said it best: nothing matters more than coding fast.

Selecting a good mentor to apprentice under is critical to your long term success. If you pick the wrong one, you will be mistrained, which will cripple the rest of your career. Without a gauge as to who is good at their job and who isn’t, selecting a mentor is a difficult process. Over time, as your knowledge of what makes a good mentor improves, you may end up switching mentors, but you still need to pick the first one. You want someone who will continually push you to the next level by forcing you outside of your comfort zone. You also want someone who can be frank without being cruel, so that you will be given good advice while still having the motivation to listen to it. Still, even if you do find someone who would make a good mentor, there’s no guarantee that they will want to take you on as their apprentice.

To convince someone to be your mentor you have to demonstrate your willingness to be subjugated. Today, the word “subjugate” has fallen out of favor due to it’s negative connotations, but it is accurate in describing the superior/subordinate relationship of master/apprentice. Someone has to direct, the other has to follow, or it doesn’t work. Subjugation means following what you are directed to do, and – at times – without question. If you are unwilling to do this, you are not ready to be someones apprentice. Knowing that you are entering into a relationship of subjugation, the pressure is on you to find someone that you respect so deeply that being subjugated under them fills you with a sense of pride. In the tough days to follow, this alone may be all you have to keep you from quitting, and making to all-too-common mistake of attempting to learn a job on your own.

That should’ve caught your attention, because being Agile is all about avoiding doing repetitive and the dreaded support tasks, probably the worst resource drain for many daily Ops scenarios. By embracing but a few ideas of the Agile Manifesto — ideas such as simplicity, sustainability, process and teamwork — there is a clear and measurable difference in minimizing the need to dragon-slay on a routine basis. Keeping things simple, eliminates the devotion of time required for grasping non-standard or incompatible [ or worse, non-compliant ] solution offerings. Instead, look for broadly adopted and commonly-accepted practices and technologies.  Leveraging them will lead readily to sustainability between the users and their demands, the business case requirements and operational effort because you’re not wasting time to troubleshoot some obscure feature in a proprietary package.  Sustainable also means creating processes, be it deployment or monitoring, that address challenges intrinsically as opposed to reacting upon exceptions.  Focus on the teams and you’ll focus on the people.  Focus on the people and invariably customer service will improve, and with that, customer satisfaction.

I’m writing in generics, because despite all operations being the same, no two are truly alike.  However, with all the advancements within reach, from utility computing to automation, you won’t have to look very far to find immediate and applicable Agile tenets in every day Ops-life.  Keep it simple. Smart design.  Collaborative.  No support.  No support means less work, in layman’s language. Next thing you know, you too will be just another hip and Agile guru.  Thank goodness you won’t have to write code… who’d want to do that every day?

“Obviously, all houses start with a foundation, so we should start there. This is a costly task, but since it’s a required for in order to building the rest of the house it should be our first one. What’s that? Oh, yes, of course, I assumed we were already connected to utilities such as water and electricity ahead of time, but if you guys want I can move those to the top of the priority list. Now, once we have the foundation, we need to put up the walls, as logically a house needs walls after the foundation. Sorry, I didn’t catch that…yes the walls would of course have places for the doors and windows to go, I figured that went without saying. However, I think we can all agree that you first need to put the walls up before worrying about the doors and windows. OK, now once they’re fully painted…uh…yes, I suppose it would be a good idea to wait until the doors and windows were installed before we did the painting. Good point, I’ll make a note of that.

“With the walls up, we can move onto the roof. Yes, sorry, I’m listening: What if it rains and the inside of the doors and windows gets damaged? Aren’t all doors and windows weather-proof from both sides? OK, well if we need to have a roof first, we can move adding the roof before the doors and windows but after adding the walls. OK, with foundation, wall, roof, and doors and windows in place we’re pretty much done, and just need so finishing touches that shouldn’t take that long – which is good as we will only have a week left to the project. I recommend that in order to make our deadline, we should focus on only adding the most important features first, which are the kitchen and bathrooms. It has one kitchen, and 3 bathrooms, and since the project plan calls for 4 people working on the kitchen, and 2 people working on a bathroom, we’ll need 10 people working in parallel to get it all done. Oh, I didn’t realize that was outside of the budget. Well, looking at the sub-tasks, it looks like electrical and plumbing take the majority of the time, so we can either cut those or reduce the number of bathrooms. I agree, electrical is something we move to later phase of the project, as we can give them portable lighting in the meanwhile. Also, we can cut toilets until the next phase – they can just use the sinks. Wow, sorry about that folks but it looks like we’re running 15 minutes over our 2 hour meeting time. I’ll reschedule a follow up meeting for later this week, and continue working through this list. Personally, I feel like we have enough of a priority list to tell the construction team to get started, so not getting through the entire list today won’t cost us any time. Good job everyone!”

Well, shit. That means that I’ve personally written rather a lot of legacy code in my life — especially before I started practicing Test-Driven Development. While TDD prevents me from making this conscious and inexcusable mistake now days, that doesn’t retroactively absolve me of the thousands of lines of untested code I’ve certainly written in the past. I’d even bet that a large portion of the legacy code I’ve written is still in use — still causing companies major headaches and heartburn. It might even be costing them major money. They’re having to pay for my lack of professionalism in my craft.

That stings, but here’s the real punchline: if legacy code is defined as code without tests, and making changes to untested code is extremely risky, then making changes to legacy code is, by necessity, extremely risky: a equals b equals c. Now that really sucks, because legacy code is commonly the source of many problems in applications, and consequently, the source of necessary changes and refactorings. Once you have legacy code, you’re already in a tough situation, and there’s not a ton that can be done to really reduce the risk of your [necessary] refactorings. For this reason, legacy code is easier to prevent than to cure, which is to say, if no one wrote any code without tests, there would be no more legacy code, and a huge chunk of the risk involved in the day-to-day maintenance of an application would drastically diminish. Learn from my mistakes, please. For all of us: don’t leave behind a legacy of legacy code.

A quick examination at the average person clamoring for corporate training will yield some funny and painful stereotypes:  People who abuse training as vacation time away from their job.  People who are required to undergo training, the result of an issued edict to address some chronic or systemic problem.  Last but not least, people who are truly incompetent, and despite countless hours of training, shows little signs of improvement and continues their mediocrity in the work place.  Of course these are anecdotal, but there is enough resemblance to real life that most won’t disagree with what’s been depicted.  None of these should be the prominent figure in the training picture.  People who are genuinely seeking betterment of themselves should have an opportunity, and the tools, to help achieve those goals.  Companies should be able to rely on training for those improvements, and with measurable results to justify the investment made.  The overall process should be flexible, and adaptive, so that the impact adds to the whole as opposed to detracting from efficiency and productivity.

It’s not an impossible scenario, but one that requires doing the right things, with the right kind of resources.  Management has to become smarter in selecting the appropriate training platform.  Human Resources prefer continuing education to be more than a slogan on a pamphlet.  People need to take accountability of their own advancement.  The truth is, anyone can train given the right combination of incentive, pace and guidance.  Before you sign up, or sign off, on next year’s training budget, make the choices that will yield the desired results.

The voters were instructed to punch holes in their ballots beside the candidates they were electing, and the ballots were then to be automatically counted by a machine that would process the placement of the holes on the ballot. For most of the voters, punching a hole completely through their ballot was not a difficult task. For the ballots in question, however, the common case was that a hole appeared to have been started, but the chad — the circular paper cutout that previously filled the area that the hole now resided in — had not been separated from the ballot, but was instead left indented into the ballot. These were referred to as dimpled chads; they were imperceivable by the tallying machine because they weren’t actual holes in the paper, and they were confusing and controversial for the human panel that would ultimately have to apply both visual and tactile inspections to the ballot in order to determine what it was trying to say.

The dimpled chads were unclear about the voter’s intention. Whether by a fit of acute insanity, profound incompetence, or extreme laziness, the voter had abused the opportunity to make a clear, obvious statement of their intent in this simple system, and had instead turned a process that should have been deterministic, thoughtless, and automated, into something tragically fuzzy, discreet, and manual. As you might have expected, the human committee that deliberated over the tens-of-thousands of ballets were constantly arguing, negotiating, and collaborating their way to an answer that they felt was a reasonable representation of what they assumed the dimpled chad was suggesting about its voter’s intent. ”Okay John, very good. Anything useful today?” Yes, Reader. Presented for your viewing pleasure: a verbal, protracted metaphor about software.

In sports, we have competitions and trophies; In academia, we have grades and degrees; In corporate America, we have titles and compensation – but titles are perfectly meaningless and compensation is based primarily on your ability to negotiate. When you get that promotion, is it truly reflective of where you stand on the world stage? Are you now in the same ranks as those with the same title at the top institutions on earth? No, probably not – at least not day one. If you claim that you are at the top institution on earth (and how you would claim that is beyond me), how do you know that there’s not someone more brilliant, hard working, and effective than you at an organization you’ve never heard of? Even if you are – irrefutably – the best at what your do, nothing says that you’ll stay there. People are constantly evolving and improving, and they won’t send you a memo when they’ve surpassed you.

There are those who are entirely self-motivated: They require no external validation to continue to improve. Even in the face of harsh criticism, they will continue on their chosen path no matter the cries of the naysayers. They are disciplined and determined, and are to be admired. They ignore external achievements, as they perceive that they will never be good enough. Winning competitions, good grades, and getting promoted mean nothing to them, because in the end it is only their self-assessment that carries any weight. If knowing how good you are compared to others is your motivation for improving, they you will never hit your full potential. The only true way to reach your peak is to look inwards, and be your own greatest critic. In the end, your abilities may or may not go recognized, but keep trying – the world needs more people like you.

There are just as many interruptions in the daily grind of systems and operations, and while it may be difficult to fathom, there are also more fires to put out on a regular basis.  These fires represent the same kind of disruption that software engineers bemoan about when it comes to productivity.  Disruption kills productivity.  If there was only a way for the tasks to be smaller, so that an administrator may work on pieces of a task without having to wrangle the entire [ day of ] story all at once, especially since fires may introduce new tasks previously un-identified in the same story.  At the end of it all, there is also an order to troubleshooting, or deployment, or administration, that lends itself to automation.  And what do you know, the first “S” in SLA stand for Service… OK, OK, I’ve droned on long enough, do you see this pattern emerging yet?  Agile may be readily applied to operations, especially system administration, for the very same reason that your software development team should be agile.

On the road to delivering resources for developers, production and thus serving the business itself, operations need to deploy rapidly, monitor vigilantly and automate so that time could be spent elsewhere.  Systems have to be up.  Data must be safe.  Priorities must be met.  All these and more demand agile practices within the teams, regardless whether the output is lines of code, or minutes of uptime.  Let go of the monolithic notion of tight and centralized control.  That time has passed in the current era of commoditized technology. The smart and savvy ops people have already moved on — they’ve embraced the same principles that drive effective modern software teams.  They’ve gone agile.

Long before we can discuss what features to cut, or how to make money if we do, we have to first become comfortable with this inverted proportion: As number of features increases, usability decreases. No amount of hand wringing or fervent objection is going to change this fact, as it stems from the way in which the human mind functions. Rather that rail against the concept, learn to embrace it and work with it: You degrade the user experience with additional features.

Rationally then, the question should be how much do you care about degrading the user experience? If you’re honest with yourself, not much — especially if your livelihood depends on it. The world’s most successful software companies suffer from extreme feature bloat and are enormously profitable. Perhaps you care from an aesthetic standpoint, or an ideal that all user interfaces should be easy to use, but also don’t forget that you’re running a business. If at some point your business would benefit from a more usable user interface, before enlisting the help of user interface experts, look first to your feature set and trim out the 20% that go unused. You may as well — it will be the first bit of advice any user interface expert worth their salt will give you.

When BMW created an access point for non-franchised garages and mechanics to be able to pull diagnostics and interact with their sophisticated vehicles, they never intended for criminals to re-program illegitimate keys ad-hoc, and with ease and expediency for car theft.  When financial institutions added forgotten-password retrieval and reset routines, they never expected that a lingering password retrieval session could be hijacked and used for logging in without any credentials.  Amazon’s own “elasticity” stretched past breaking recently, because of an anticipated failure recovery created over subscription of the very Amazon Web Services provided, during a problematic power period caused by Mother Nature’s record-breaking heat wave.

In each of these scenarios, engineering teams went through rigorous design and review to ensure they addressed the planned or imagined use cases, individually.  Project managers watched as QA performed the required tests.  They absolutely delivered what was asked of them in terms of product and functionality and usability.  Yet every single one of them failed in such a way that leads to pondering, how could this not have been thought of?  Ironically, it is the efficiency at solving the original problem — allow access, reset credentials, shift to a different resource pool – that in turn created an entirely different monster.  Their design satisfied their singular and original intention.  Will your silver bullet bring out the boogey man underneath the bed?

Imagine for a moment if your team rallied behind this unified vision of always leaving your codebase cleaner than when you opened it. How would that affect your approach? Would you think more about the changes you were about to make? I certainly did. I thought about how I felt about whomever had been here before me and had left this monolithic catastrophe. I also thought about the person who would spend some time here after me and who would have to clean up whatever mess I decided to leave behind. I thought twice, and I cleaned up. The Boy Scout Rule helps you think about the code you’re writing in terms of how it will affect the next person after you, and how it contributes to the system as a whole.

Most importantly, however, is that it encourages you to make small, incremental improvements. No improvement is too small. Extract an interface, pick up a bottle; introduce a factory, leave behind some firewood for the next troop. This approach to software makes the monumental task of refactoring a legacy system somehow possible. It makes the codebase everyone’s responsibility; if you spend time in it, you’re responsible for it. Someone may want to use the campground after you, so clean it up, ok? Every little bit helps.

People tend to be entrenched on the subject of bug bounties — and conversely, bug bounty programs. Companies on the opposing side of this idea, which include some of the biggest names in the industry — Adobe, Microsoft, and Apple – they do not believe in rewarding others for vulnerability discoveries, at least not in monetary terms. Meanwhile, they are the same companies that routinely struggle with reactive security patches and frequent egg on their face, when defects leading to mass breaches comes to light. Proponents of this “radical” idea of bug bounty include Mozilla, Facebook and Google, who’ve been able to reap the benefits of crowdsourcing bug researches, and both publicly and monetarily acknowledge that effort. To that list, we must now include PayPal, who’ve announced an update to their bug reporting system to include a paid bug bounty program. This is a huge step, when a financial company is ready to embrace such programs. It’s not some leap of faith, “data has shown it to be an effective way to increase researchers attention on Internet-based services and therefore find more potential issues.”

Just as award winning directors need a separate set of eyes to aid in editing to preserve and enhance the integrity of a film; software companies need the scrutiny of outsiders, especially when the Internet is on the other side of the threshold. PayPal’s steps down this path should be lauded and others should take notice… if a company whose core business is financial transactions, and the corresponding challenge in preventing the misuse of their systems, have endorsed that bug bounty is the appropriate approach… what’s holding your company back from adopting a similar program?  In that debate, the gallery of witnesses now includes more than just grass root supporters of open source projects, it includes real companies needing a solution to some very real problems.  Time to discuss the same need within your organization.

“The meeting outcome” is almost a dirty phrase. Clearly, those who wish to know the desired outcome of a meeting before the meeting simply wish to avoid the meeting. Try this experiment: The next time you receive a meeting invite, reply with a polite email inquiring as to the desired outcome of the meeting. Take your time, and phrase it carefully so as not to offend. Try as you might, you can’t avoid the insinuation that the person calling the meeting did not give enough thought to the outcome. If the reply contains an agenda, consider yourself lucky, but avoid the temptation to remind the meeting organizer that an agenda does not outline a desired outcome.

If one were to focus on the desired outcome of a meeting, many meetings would be radically altered and/or canceled altogether. “What do you want to happen as a result of this meeting?” is not a complicated question steeped with emotion, but it is often greeted as such. When I meet with my accountant, I want to know how much I owe in taxes. For that he doesn’t even need a full email – a text message will do. When I meet with my auto mechanic, I want to know what is wrong with my car, and how much it will cost to fix it. This can be related over the phone in less than 10 minutes. When I hold a “design review” what do I want as a result? When I call a “team meeting” what is my objective? Perhaps if we start with what we want, and then afterwards consider if a meeting is necessary, we can save companies hundreds of wasted hours of productivity a week.

Rapid understanding seems intuitive, but is actually quite difficult. Even with a masterful understanding of whatever language(s) the codebase happens to be written in — and not to downplay this, that helps tremendously — it can still be extremely difficult to actually understand what some lines of code are accomplishing in an unfamiliar domain. Almost always what ends up being most difficult to understand were the intentions behind the code. Of course, you had an initial requirement to make a change that lead you to explore this part of the code to begin with, and you likely came up with an idea of how you thought existing functionality would work, and what type of change you needed to make. After rapidly understanding the code that’s actually there, you’ll likely find that you made some incorrect assumptions. Now it’s time to adapt your design to fit within the constraints of the code that’s actually there. Alternatively, you could try to adapt the existing code to facilitate your optimal design, but this can be difficult in codebases that aren’t cooperative.

Finally, the actual implementation can seem easy, until it’s caveated with “bug-free”. An all-too-common post-mortem of code changes in legacy systems is counting the ways it broke pre-existing functionality, sometimes in the most obscure, non-obvious ways. Unfortunately, I’m not aware of an awesome, immediate fix to this problem. It usually requires invasive testing of legacy components, and potentially risky refactors — reducing the risk of which can be exceedingly difficult. However, as for the code you’ll be writing, test-driven development and pair programming are essential to bug-free modifications. We’ll talk more about reducing the risk of legacy refactors next.

The stupidest thing I’ve ever heard as it related to rollbacks was from – off all people – a chief architect. The statement was, “We never rollback, only forward”. Said by a military general in the face of overwhelming odds this may still not be prudent, but at least it’s inspiring. In this particular situation, customers were going berserk, data was being lost, and it was during prime business hours. Why in gods name wouldn’t you roll back? Comes to find out, there wasn’t a rollback plan.

I want you to listen to me when I say this: Whether you are deploying the simplest application in the world, or the world’s largest website, you must have a rollback plan. Murphy’s law works overtime during a deployment, and sh*t will happen that you cannot anticipate. Rather than put the business at risk, you need to pull the plug, call off the deployment, and restore the app to a working state. This is a strategic retreat, not an admittance of defeat. There was a flaw in the deployment plan, and you made a wise choice. Now you can figure out what went wrong without customers losing their minds and the database purging terabytes of data. With the ability to rollback from anything, you’ll never panic during a deployment again. When things go screwy, you just hit the big red rollback button and go back to sipping Mai-Tais, thinking of how they’re just handing out chief architect titles nowadays.

The first time I wrote a BASIC program, it occurred to me that I had just created something from nothing. Where previously there was no logic and no design, I had been able to manifest my ideas through code. All I needed was a low-fidelity text editor (and GW-Basic), and I could create hundreds of different little procedures and subroutines to play tic-tac-toe, or keep track of to-do lists — my imagination was my limit. This was huge. That feeling of inspiration and encouragement, knowing I was in a realm of pure creativity, is something I’ve never forgotten, and still attracts me to my craft today. Only now, it’s being influenced by different programming paradigms and techniques.

Rediscovering and remembering why you love your craft is something software engineers should do as often as possible, if for no other reason than that our jobs can become excruciatingly mundane if we allow them. Learn a functional language, or design a DSL for customizing your dream car. Work to recapture what attracted you to your craft to begin with, so the next time you think “if I have to refactor one more service…”, you’ll consider how amazing it was to be able to create a digital service that aggregates millions of users based on their first name to begin with. In fact, you might even consider how amazing it is to be able to deal with a million of anything to begin with.

Services are not free.  Features are not give-aways.  Even without explosive growth, companies have to maintain break even to sustain operability.  And when the revenue does not come from the users themselves, then the practice of selling the data based on collected behavior must continue. That information is valuable and the cost of gathering that information pales in comparison.  Billions in revenue.  Millions in cost.  So companies will create addictive and compulsive products only to give them away. The culling and cultivation of the masses will continue — without awareness and without knowledge, the masses will continue to expect free offerings in exchange for intimate details of their habits, preferences and lives. Worst yet, the success of companies like Facebook, Twitter and Zynga inspire new generations of businesses with this exploitative concept as the driving force, especially when the leadership themselves espouse this ideal – “just to get revenue.”  I don’t mind the business model, except now that has become the only game in town.  People are no longer seen as customers, but simply remote sensors to provide endless data stream to feed into the machine.

Some may disagree, believing that the free services are worth the trade-off in privacy.  Arguably, the original dotcom rush of mass adoption may not have occurred as readily, without companies like Juno or Rocketmail along the way.  Except, then, there was the option to pay.  We do not have that now.  It’s become impractical to compete with the 800lb gorillas of social platforms with a pay-to-play offering.  Imagine the viability of a service without the momentum of people, and a pay wall before entry.  So not-paying is the only choice, and the vicious cycle continue, and empires continue to lock in the masses.  Users will continue to be trampled, their information traded, and their concerns largely ignored.  You have become the commodity.  You, are what’s selling off the shelves.

The reason this doesn’t happen – at all, really – is that engineers don’t know how to do penetration tests. I don’t know why, it’s a load of fun! Sure, those are the same skills that could get you landed in prison, but if you’re going to defend against hackers, you better learn to think like one. It takes a thief to catch a thief. Most engineers write software as if they’re living in a log cabin on the top of a mountain in a desolate region of the planet. Who would ever want to break into my stuff? It’s such a good neighborhood! The reality is that your software will be running on the Internet, and the Internet is the seediest part of town with crackheads looking in through your windows, looking for stuff to steal.

When it comes to security, it’s all defense. They say you can’t win a war playing defense, but you can tire out and demoralize the enemy. Every time they make a coordinated attack and get nothing, you’ve wasted their time and (if you were paying attention) learned about their methods, which then allows you to shore up your defense for the next time. Security isn’t about a one-time process that happens a few days before a release, it’s constant vigilance. They can hit and miss; you only need to miss once. If that stresses you out, then you’re starting to get into the right mindset. At least at the end of the day, by running constant pentests against your own work, you’ve done the best you can to bar the doors and windows. It may not be enough if an army comes knocking at your door, but it will at least keep the crackheads out.

And so far, no problem. Certainly there’s nothing sinister about lasting at a company through many iterations and evolutions, gaining more and more insight as time goes by. Except that this information can be invaluable to a corporation – so much so, that they’ll actually keep on an employee who’s dead weight in order to prevent the knowledge loss. This is especially prevalent in software organizations, where some legacy component or module that no one understands is at the root of the company’s revenue – maybe it’s a transaction processing class, or a driver to connect to a proprietary data source. It might not even be that complex at heart, but has rotted over time to the point that the risk involved in refactoring – or God forbid, rewriting entirely – is too much to warrant anything new. Then there’s Mort, an abrasive and irritable curmudgeon who was the primary developer on the component 10 years ago, and who has been doing everything within his power to keep the company in the dark ages, which is where he comes from, and where he’s convinced he’ll retire.

Mort is a real pain in the ass to everyone who has the unfortunate task of interacting with him, really at any level. When asked even the most direct questions about his software, his explanations are cryptic and lazily formed, and are typically so myopic they lack context, and ultimately, usefulness. Mort knows what he’s doing too, and he’s become exceedingly capable of keeping his paycheck and remaining an island. So how do you ever get any information? You can try to approach truth by writing unit tests for the legacy system that Mort wrote, but typically the code is so poor that it does not really lend itself to testability. And you can’t really ask Mort for help testing his component, because, well, it’s worked for 10 years, it couldn’t be broken! He probably doesn’t believe in the value of unit tests anyway – that’s not true by necessity, it just tends to be the case. I’ve only ever really found one consistently successful approach in diminishing Mort’s clamp on the organization’s progress: negotiating away information, little by little, and immediately socializing it. If you want to extract age-old domain knowledge necessary to retire problematic software components or archaic processes, you’ve got to learn how to negotiate with terrorists.

It’s trivial to make history. With each ticking second, with or without effort [ and to some degree, any specifically applied will ] history is being made. It’s also easy to make terrible history — cause some downtime, write some vulnerable or insecure code, and reply-all to the wrong Email, and voila, you’ve made history. Fight a fire in production, stay up all night to salvage some deployment gone-awry, or cram all the extra feature request into an iteration or release — be the [super] hero and that’s a guarantee for making history too. One historical moment followed by another, some more notable than others, but that’s not really the kind of result we’re looking for. What’s tougher is making impact, because that means having direct effect on the situation, and quite often, requires the “doing of right things.” What does that mean? It means the slow and painful, and often without recognition or glory. It is people, performance and process. It is engineering,  deployment, and security. It is all about the one, and all about the team too.

There is no short cut here. No miracle drug or Midas touch or ten-step fortune cookie wisdom. It will be slow and time consuming. More than likely, it will demand persistence and commitment, and the bad/ugly that often come with small improvements. No one will throw a ticker tape parade for continuous integration. No pats on the back for steady velocity. There won’t be recognition, because the day won’t require saving. However, that will be enough. Because more than history, impact is being made. And that’s the real difference for getting results.

As you may have already guessed, this is a metaphor. It’s also exactly what I think of whenever I hear a client describe themselves as being “mostly agile”, because maybe they like the results that Agile methodologies afford, but aren’t “sold on the process”. Maybe they do 6 week iterations, or they have a product team that can’t find any value in incremental demos if they can’t have everything all at once. Maybe they write 3 paragraphs in their Jira tickets, having completely forgotten the original point of using note cards to begin with: to provide a brief teaser of a feature that results in a real verbal conversation between two people.

Agile practitioners favor people over process; in fact, it’s the first list item in the Agile Manifesto. It doesn’t mean that they think process is useless; they merely value human interaction more, and thusly give it priority. This can be scary for a CYA-oriented product development organization – one that’s used to retaining months of Word Document revisions, emails, and chat histories, so that at the drop of a hat they can provide digital artifacts of their own due diligence, just in case everything goes side-ways. Agile can be a difficult switch, and I’m sympathetic to skeptical organizations who have only ever experienced varying gradations of success in waterfall projects. But if you’re interested in quick, iterative feedback, and if you highly value the flexibility to successively refine requirements that Agile methodologies afford, don’t try to be “mostly agile”. It doesn’t work. You’ve got to experience the process. You can’t skip the pregnancy.

The reality is that Agile is orders of magnitude more difficult that Waterfall. Waterfall is so easy, it’s the same method you use to get your kids to do chores. You tell them what to do, and they do it within the allotted time or they get punished. Honestly, if your team is made up of children, you’d do well to stay away from Agile and get good at doing Waterfall. There’s no shame in that. Some teams have the professional maturity and expertise to do Agile successfully, but most teams do not. Take a hard, honest look at the type of team you’re working with, and choose your methodology appropriately.

If you do have a team capable of doing Agile, you better at least know what that means. Ask yourself, do you even have a clue what Agile means? What books have you read? Who’s been your Agile coach? How many years have you been doing it? How many projects have you taken to successful completion using Agile methodologies? If you’re lacking in your knowledge of Agile, don’t impose your lack of knowledge on others. If you do, you can end up doing more harm that good. If you want to learn Agile, be ready to put in the work, cause it’s a lot harder than picking up your clothes and making your bed.

Imagine the same conversation occurring in a slightly different setting, between say Joël Robuchon [culinary extraordinaire] and a guy who’ve made excellent French toast for weekend brunches at home — pointing out flaws to a celebrated chef and restaurateur, because our guy cracked an egg here and there. It’s comical, and it’s ludicrous. Actually, that conversation would never take place.  Because in real life, people recognize those specialized skills and respect strength of performance, and would hesitate to disagree with an artisan on their craft. Yet this conversation of ex-developer vs. current-developer routinely occurs in our industry, within many companies and many meetings, reviews and other contentious gatherings.  I’ve observed this, and so have you.

It’s a cynical view.  The implication trivializes code creation, as the task must be simple.  It also suggests a lack of trust, of the effort and commitment required for designing/implementing a quality solution to solve the problem at hand.  It may even be an avoidance of accountability, as the responsibility is shifted away from everything else, except those actions associated with software development — surely, the project plan is immaculate, the business requirements a state of perfection and all other components paragon of flawless execution.  The wrench is thrown in the general direction of the software team because that’s the source of all things evil.  Please, think twice before this escape from your throat.  Trust me on this… I used to code.

Back to basics, so that we can convince yourselves that it’s really this easy. Back in the day, when you “deployed” a website, it was by FTP’ing static files. You connected to your server, and when you were ready, you dragged the files from the left side (your machine) to the right side (the remote machine). Presto! Your changes are live and you can go home! Total time of execution, around 5 minutes ’cause you were on dial-up and decided to use MASSIVE 25kb GIFs in your black-background-with-pink text ultra cool cyber web space site. You grew up, got a job at a large enterprise running a J2EE/Oracle stack, and for the first time learned of something called a “build process“. This build process – all by itself – took 15 minutes, and once you’ve built you are nowhere close to getting deployed. What’s even more depressing is that that’s usually the only thing that ever gets fully automated, mainly because we have to build all the time (hint).

From there on out it’s copy and pasting configurations no one else knows about, logging into administration consoles that you’ve only used a few times before, and hacking away at a command line like you were in a movie with Halle Berry. This is going to lead to a bad time, and it doesn’t have to be this way. If a computer is good at anything, it’s good at performing a thousand intricate steps flawlessly every time it’s asked to. All it needs is to be told what to do. If you’re not sure what to tell it to do, then you’ve got a another problem entirely, and having a dozen people on the phone at O-dark-hundred ain’t the way to figure it out.

It’s like the Nigerian scam. The reason why the bait Email discloses the telltale details of a Nigerian prisoner, is because that serves as a mechanism to screen out smart savvy people who would not fall for the scam. By systematically eliminating the “false positives,” what remains are the willing, and susceptible, victims. The schemers are not stupid. They are lazy and always looking for the short cut. The fact a Flash-trojan specifically targeting Macs, infected almost 600,000 computers, including some 300 from Cupertino, Apple’s own backyard, tells me that it’s not about popularity and it’s not even a numbers game. People who do not exert the effort for basic safeguard will get taken. The combination of ill-informed and lack of consciousness paints a bright glowing target. Adding an AV solution after the machine has already been compromised is a painful first-hand lesson.

Just because your user base isn’t on the scale of billions doesn’t mean your code/application won’t garner the attention of the criminals. Obscurity is never assurance of safety, and nothing appeals to hackers more than… well, identified apathy toward security. Even Apple has had to change their message, removing the “no effort” language itself. Relying on analysis after development has already engaged, or worse… reacting after the breach, should not be the primary means of eliminating vulnerabilities. Security is requirement one, when the Web is at your doorstep. It’s going to warrant involvement. It’s going to demand awareness. It needs consideration, from inception. Education is critical, and as the old GI Joe battle cry rallied, “Knowing is Half the Battle.”

The reason wasn’t because the answer was especially intuitive to me; indeed, if it had been at the time, I’d have likely written something intentionally unintuitive in order to exercise my “programming chops” in what I perceived to be a “healthy creative process.” The real reason was because building a cooperative code base was not something I cared about.

An appropriately configurable code base is a cooperative code base: one in which engineers stop asking themselves “what should I build?”, and start asking themselves “what should I configure?” It’s a code base with a rich domain model that intuitively speaks about the company’s business plan. It provides obvious, reproducible interactions between objects as compositions of smaller, valuable features that might one day be used to compose other objects. Simply put, a cooperative code base empowers it’s engineers, rather than restraining them. So the question is, are you empowered by your code base? Or are you its hostage?

Utility computing is out of the proving grounds. This is the era of clouds. An instance is like a physical server, except it’s not. Elastic or other cloud-based storage is like a disk, except it’s not. Virtual server is like hardware, except it’s not. Instances are ephemeral. Storage is now a network. Virtualization implies multi-tenancy. Understand what the technology represents and assemble the building blocks accordingly. Amazon is not the only game in town. And if it’s too late and you’ve already gone all-in with EC2, have a firm grasp what Availability Zones really mean, and integrate that into the design. No one would rely on a single pipe for bandwidth, or a single power/UPS grid for electricity, so don’t place all the eggs in one US-East-Virginia basket. It’s time to look past yester-year’s data centers. These are the new tools to create some fantastic, resilient and modern infrastructure.

Combine that foundation with automated deployments, it is now rather trivial to stand up another stack at a moment’s notice, anywhere. Grab the latest stable code, push out the approved content for delivery, restore from the current database backups, apply the verified configuration files, and start turning up some [fresh] servers. Execute the smoke tests, re-point DNS and just like snapping your fingers, the sites are all back up and running. Suddenly, the unplanned downtime is about as long as a scheduled maintenance window. There is no need to blame the tripped cords. This is not a dream. Make it the reality already.

We often miss the opportunity to just blurt out, “That sucks”. Look, if it sucks, it sucks. If you created it, try to make it not suck. If someone else did, tell them it sucks. Don’t try to sugarcoat it – that’s like slowly peeling off duct tape. Just say, “that sucks” and get working on the next, highly productive question: Why does it suck? It probably sucks because it’s ugly, clunky, or hard to use. Pick one and start there. If it’s ugly, hire a graphic designer with a portfolio you like, or hold an online design competition. If it’s clunky, dump features until you’re back to the core features everyone wants. If it’s hard to use, ask people to use it with you looking at them, and when they can’t figure something out change it so that they *can* figure it out.

Decades ago, there weren’t that many user interfaces around, and they were really expensive to create. As a result we needed a lot of PhD’s huddled around a chalkboard to figure out the best user interface before investing millions of dollars in creating one. Today, we can whiteboard 3 user interfaces in an afternoon, and build a working prototype the next day. We don’t need to read textbooks just to understand where to put a button or a check-box. All we need to do is look at the sites and applications that millions of people use every day. Even if you don’t particularly like a user interface, you at least know millions of people know how to use it. Remember, if you’re going to tell someone their works sucks, you better be ready with an alternative, and there’s no better alternative than pointing to the user interfaces of highly successful products.

Researchers from University of Heidelberg in Germany, have published their latest studies and findings, which fundamentally state that the intimate details not disclosed by an individual, “can nonetheless be inferred with high probability [of accuracy],” if the person’s network is sufficiently revealing.  I suspected this was always the case, as people tend to be drawn to those with similar interests, alignments and preferences.  Except now a group of scientists have confirmed this with good science, and demonstrated the math for extraction… and my fear, written a howto guide for potential exploitation.  What’s even better worse is to have the largest sample to draw from, in the form of Facebook.  Or like CarrierIQ.  Or dozens of other examples where this massive collection is taking place.

In this modern era of GPS-enabled, self-publishing and continously monitored life, it will be a struggle to find the balance between leveraging that derived information for good — such as urban planning and traffic management — vs. the bad, and become a revenue profile for marketeers. Please, no more ads.  My daily life shouldn’t be simply another remote beacon for measurement.   Despite my own efforts, my friends have sold me out unwittingly.  The old adage is true:  no man is an island.  I am no exception.

The problem is that you don’t find talented engineers — they find you, which means your effort should be primarily spent on creating a culture that attracts them. Am I really suggesting there might be a better approach than farming your hiring out to recruiting firms who cold-call and spam their way to profitability, who themselves haven’t the first clue as to how to find talented engineers? Probably not, if you’re looking to impress your CTO, who’s asked you to add 15 more engineers before next quarter. However, if you’re looking to hire top-tier engineers, don’t call up your local account managers and hiring executives who will just scour your area for the Usual Suspects.

Work on changing your culture, introducing them to things like Test Driven Development, Domain Driven Design, Pair Programming, S.O.L.I.D. Principles of Object Oriented Programming, the list goes on. Work on finding someone who wants to bring those things to your organization, and convince them that you’re committed to doing it. Finally — and this is key — hire a team to help. You’ll find talent is attracted to talent.

The key to the word “service” is that is provides something to someone else. If you’re the only consumer of your service, it ain’t a service, it’s probably just a transport protocol or a marshalling strategy. A “service” is just like a real life service you would get from restaurant or a clothing store. It’s something that you need, and if it’s good something that you’ll want to use again. Services should be friendly to the people who are using them, so that they want to keep using them. They should be designed with the consumer in mind, and provide a pleasant experience. If you service does the equivalent of spilling coffee on your lap or ignoring you while you have a handful of clothes and can’t find the dressing room, then it’s not a very good service.

The problem here is that the design of services is really a usability concern. The designer is a developer, and the consumer is a developer. It’s the first bit that’s a problem. Developers often could give a damn about usability, and are usually only myopically focused on the task directly in front of them. We figured out years ago that we shouldn’t let developers design user interfaces, but now we’re giving them free reign to design services for other people. If you want to design a good service, do the same thing you would if you were designing a good user interface: Figure out what the customer wants, give them what they need, and then watch how they use it to make sure you did your job well. Anything else is just you coding in a vacuum writing a service no one wants to use, or hates using.

All this fuss over passwords, because people have this misconception that passwords equate to security. For the record, NIST acknowledged in 2004 that SHA-1 is deprecated for various insecure reasons and will be retired as a standard by 2010. Two years after the fact, a leading technology company with over 150-million users is using this encryption algorithm to store passwords. Quite the mind boggling and mind numbing technology sin. Password is not security; it’s not even a security blanket. It’s authentication and hardly adequate in the modern, hostile web. LinkedIn should’ve known better.

Besides, the focus should not be on the fact that 6-million hashes are in the open — a meager 4% of the user base (although I believe the breach is likely much worse) — but what is happening with this very large set of information. Regardless of the objectives of the the initial breach, the [hacking] business intelligence that may now be derived from heuristic analysis is highly productive, in driving refinements for future brute force attacks and/or gauging patterns and frequencies, and in general, increasing future success against the general public. Not to mention, combined with the saltless SHA-1 decision blunder, the chance to create rainbow books and exercise massively-distributed computations. Good day for the Black Hats; bad day for the rest of us. Anyone who thinks it’s not a big deal because logins weren’t included is missing the big picture.

Let’s go back to the basic fundamentals of business: For a business to succeed, it needs to make more money that it spends. The difference between how much you spend and how much you make is called “profit”. Businesses want to maximize profit. When your idiot little brain decided that a 3 deep nested loop that results in hundreds of SQL queries being issues per HTTP request was a good thing, and then you decided the solution was to spend more money to keep it running, you ate into profits. Why? Because you’re too lazy to learn how to use a RDBMS properly. There’s a manual, read it. There are ways to avoid making hundreds of SQL queries — you wouldn’t believe how many ways! It’s almost like database manufacturers wanted to make sure you didn’t *have* to make hundreds of queries to build up the data set you were trying to get.

Any old fool can write software that works. It’s a deterministic system — give it the proper inputs and it will give you the proper outputs — every time. However, it takes skill to write software that uses the hardware efficiently. Bear in mind that if you decide to stop designing your software so that it’s maintainable and extensible, you’re being a different type of idiot; but if you disregard any and all performance consequences and brutally molest system resources, you’re not just an idiot, but you’re also costing the business money. The good news is that now with cloud deployed applications we can directly correlate how much more money your bone-headed implementation is costing us. Personally, I think we should take it directly out of you paycheck, ’cause after all, “Hardware is cheap”.

Someone convinced an AT&T technician to re-route the subscriber’s cell phone to a fraudulent voicemail box. No code hacking, no PBX re-programming. No physical breach of wires. The heavy lifting in this breach involved conversation. The first of four dominoes fell, as seen on this timeline, when un-authorized access was granted, by an employee, to some untrusted outsider. Sure, there are clearly flaws in Google’s 2FA, they’ve admitted that. And CloudFlare’s auto-cc of administrative Email containing sensitive information, that’s just bad practice all around. However, those attack vectors weren’t so handily exploited, without the initial ability to redirect the trusted channel of communication.

There are plenty of technical discussions else where, about code and process and race conditions ad nauseam… but the bottom line is this, the weakest link is “people” and exploiting people’s behavior has been security’s greatest foe since walls were made of stones. More technical solutions won’t fix this. In fact, increased complexity and the ensuing decrease in usefulness, will only create additional opportunities for human error. Awareness, instinctive or trained comprehension, is likely the only way to counter being talked into unlocking the door.

In many ways it’s a form of hazing: First, you are met with constant negativity in that everything you are asked to do is in terms of something that is broken, which you are now responsible for. Second, when you are asked to fix something, you are expected to immediately come up with a time frame for when it will be fixed, which is completely unknowable. Third, you will encounter every type of obstacle software development can throw at you, to fix even the simplest things (a text change could require learning how to build and deploy a 10 year old application!) And finally, upon the successful fixing of the bug, you are not greeted warmly with praise for doing the impossible, but instead are nonchalantly handed the next set of bugs to fix.

Maintenance is a rite of passage all engineers must pass through at some point in their careers. In many ways, it’s a very good thing. You will suffer through the agony of wading through gobs of poorly factored poop, which will help you appreciate clean code. You will learn what it’s like to have absof*ckingly no clue how to go about solving a problem but have to solve it anyway — on a schedule. Appreciating clean code, and learning to persevere, regardless of the obstacles and time pressures, are hallmarks of excellent engineers. I know from at least one personal experience that great engineers can be born from the hell-fires of maintenance.

You look around the room at engineers you’ve never worked with before. You wonder if you’re the only one who realizes what’s really happening, and if you are, how you’ll tell them that they’ve just been suckered into long, stressful nights and weekends as far as the eye can see – slaves to an immature product team that has yet to produce cogent requirements or decent story descriptions, and who have completely lost faith in engineers as a whole, if they ever had any to begin with. Don’t try to save the day – it won’t work. This is about survival, not foolish heroics that will ultimately lead to a credibility bankruptcy.

Still not convinced? Try this: you are 3, maybe 4, iterations away from hearing the same people who got you into this mess tell you that “they could build this product in 2 weeks” and that the team “isn’t moving fast enough”! By then, it won’t matter that for the first time in the history of the organization  a team is actually meeting their timelines and delivering on requirements, establishing a lasting relationship of credibility and respect with product, and demoing real functionality every Friday. All that will matter is that the unified, self-sustaining team you will have grown so fond of will be on the brink of becoming line workers. The control has already started shifting, and your team has a crucial decision to make: will you stand, or will you fold?

Proficiency isn’t just technical know-how. It’s also about abilities to lead, the capacity to manage and the resourcefulness when solving problems. It’s all of that, and surprisingly, being proficient is not necessarily being successful in the past or having performed the [same] task already. It’s about the “Can Do.”

Passion comes after Proficiency, because despite the best of intentions, without the accompanying skill set, all the drive and desire won’t translate to accomplishment. However, without passion, it is impossible to work hard and more importantly, work smart. There must be a fire burning for the engines to run, to excel and to achieve. It is passion that will directly translate to enjoyment of the job.

Finally, Personality. This isn’t cubicle decorations or dress code or taste in music. It’s all of it and more. Individuals who are smart and passionate, but are toxic to the team helps no one. It doesn’t matter if it’s a superior, a peer or an underlining, ill-fiting pieces lead to incohesive team and worse, assured inefficiency. The last requirement for candidacy comes down to the very simple — playing well with others. And that, is all about the different personalities.

I’ve been formulating the 3 P’s for a while now. And with my current endeavors, I’ve the opportunity to see some regular occurences across different companies and interviewers. The right fit, across both side of the desk, will come down to a company and I matching our Ps.

And why should they? Changing jobs sucks, almost as a rule. People get attached – it’s what we do. Whether it’s to another person, a pet, or a job – we get comfortable, and time passes. Before we know it, what was new is familiar, and what was current has become nostalgic. The seemingly simple act of leaving a company is a challenge unto itself. I’ve felt relieved after leaving bad companies. I’ve felt neutral when I left better companies that were sorry to see me go. I have never before felt bittersweet to leave a company I enjoyed working at.

I’m feeling that for the first time right now, and it’s teaching me two things: first, figure out your dream job, and second, find a good reality job. If dream jobs are the jobs you want, reality jobs are the jobs you get, and I got hired for a really great reality job 8 months ago. I’ve honestly had a blast, and it’s been very rewarding. It also helped position me to be able to accept my dream position as a software craftsman with ThoughtWorks. I’m grateful to be in such a privileged situation, and I’m very grateful to have had a reality job that helped make my dream job, itself, a reality.

In helping me plumb the depths of what could potentially be the character flaws that may have lead to my arrogance, my close friends are no help. They are made up of doctors, lawyers, successful business owners, wealth managers, physicists, architects, programmers, hackers, executives, ex-military personnel and athletes; and either they don’t find me arrogant, or are labeled as arrogant themselves. “You’re just extremely confident,” they say. If extreme confidence can be labeled as arrogance, then I don’t want the characteristic. But then how does one “tone down” confidence? The strategy that has worked best for me is to avoid conversation with people who don’t already know me, which has lead me to being perceived as socially awkward at best, and anti-social at worst. I often worry that this strategy of avoidance leads to the label of being too arrogant to talk to regular people. It seems I can’t win.

Faced with the empirical evidence of arrogant people finding me not to be arrogant, yet everyone else (forgive the hyperbolic paranoia) finding me to be so, I am forced into the conclusion that I fear is nothing more than a cop-out: Maybe being perceived as arrogant is entirely dependent on your audience? Perhaps in certain circles, you are considered having the appropriate level of confidence, while in others as having so much as to be labeled conceited or condescending. I would like for this to be true, as everything I have tried to be broadly accepted as non-arrogant has failed for so long on so many levels that it would alleviate the persistent guilt and self imposed shyness that has come to define my adulthood. I can only hope that my worst fear is not realized: that the contemplation of one’s own arrogance is the epitome of arrogance in and of itself.

1. Legislation will solve help the situation
2. Only the end points [user/web] has access to this information
3. Technology will remedy human behavior
4. There is a grand unifying umbrella for everything, for anything.

People identify with specific “trust gaps”. By focusing attention on remedying just one/a few, the bigger picture is that the machinations of the web have always demanded the disclosure of information, in the name of sharing. The explosive growth has demonstrated the power in sharing, and I do not expect it to reverse.

It is still a good practice to be mindful, and to mitigate risks. However, resistance is futile, and welcome to my thoughts.

Whether this occurs or not is dependent entirely on how much the engineer cares about there being bugs in the system. Fact is, most engineers don’t really care, using the rationale that bugs are simply by-products of developing software, and that having a certain number of bugs should be acceptable. Furthermore, some bugs are minor, and should be de-prioritized in favor of higher priority bugs, so really there are some bugs that will never be fixed by virtue of responsible prioritization. This all sounds reasonable and defensible, doesn’t it? Heck, most people reading this would say, “Hey! That’s the process we use!” Yeah, it is – and your engineers are gaming the system.

The truth of the matter is that these types of engineers are typically lazy bastards and are unaffected by the presence of QA — they will do whatever they feel like, largely because they are allowed to get away with it. If you work with these types of engineers just figure out what they did to get such a sweet deal, and get career tips from them. They’re probably on a fast track to management. The engineers who benefit most from not having QA are those who are not lazy bastards. These are engineers who take pride in their work, and don’t want any bugs in their system, but who make honest mistakes. Without QA, these engineers get better as they develop the self discipline required to thoroughly test their work before declaring it done to anyone. In terms of bang for buck, you’re best off keeping your novices away from QA so that they learn how to produce quality code on their own.

Novices fall into two categories: Those who can get better with training and those who can’t. Separate your novices into those 2 groups, and focus on training the ones who will get better by investing in them. We like to believe that everyone can get better at their job if given the opportunity, but that’s not true. Some people are novices not because they don’t yet have enough experience or knowledge, but because they’re lazy and/or not very smart. Don’t waste your time with them. You’ve got a business to run, and you need to separate the wheat from the chaff.

Once you’ve dealt with the politics involved in only investing in training some of your team, it’s up to you to personally oversee their training. Don’t just ship them off to some training center and hope the come back more productive. They’ll probably just take the week off as a pseudo vacation. Instead, roll up your sleeves, clear your calendar, sit next to them, and really train them. See how they do their job every day, and coach them on exactly and precisely what they need and where they need it. Taking a novice to proficiency may not alleviate the need to hire more staff entirely, but it may delay the necessity of it – not to mention saving you a bunch of money and headaches.