DaedTech

Stories about Software

By

The Importance of Performance on the Development Side

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at their offering for monitoring your software in production.

In the software development world, we pay a ton of attention to the performance of our code in production.  And rightfully so.  A slow site can make you hemorrhage money in a variety of ways.

To combat this, the industry has brought some of its most impressive thinking to bear.  The entire DevOps movement focused on bringing things to production more efficiently and then managing it more efficiently.  Modern software development emphasizes this, staffs for it, and invests in it.

But looking beyond that, we leverage powerful tools.  Monitoring solutions let us get out in front of problems before users can discover them.  Alerting solutions allow us to configure those solutions to happen more effectively.  Entire organizations and industries has sprung up around creating seamless SaaS experiences for end users.

But in spite of all this, I’ve found that we have a curious blind spot as an industry.

A Tale of Misery

Not too long ago, I sat in a pub having a beer, waiting on my food to arrive.  With me sat a colleague that works for a custom app dev agency.  In this capacity, he visits clients and works on custom software solutions in their environments.

Over our beers, he described their environment and work.  They had some impressive development automation.  This included a continuous integration setup, gated builds, and push-button or automated deployments to various environments.  And once things were in production, they had impressive instrumentation for logging, tracking, and alerting about potential issues.

I told him that he was lucky.  He countered in a way that caught me a bit off guard.  “Yeah, it’s impressive, but actually working there as a developer is pretty rough.”

I asked him to clarify, so he did.  He told me about having to use slow, old development machines.  He talked about unit test suite runs taking forever locally and even longer in the build environments.  They had a lot of best practices in place, but actually getting anything done was really hard.  Even the source control server was flaky, sometimes kicking back attempted commits and creating issues.

This struck me as a fascinating contrast.

Read More

By

Deploying Guerrilla Tactics to Combat Stupid Tech Interviews

I’ve realized something about my situation.  I work for myself, building businesses and still, occasionally, consulting at times.  But of course that’s not news to me.  Nor is the fact that I’ve moved out to a quiet, remote place where I wear T-shirts exclusively, fish a lot, work when I feel like it from a room in my house, and often cook dinners over a fire in my backyard.  The realization came from marinating in that lifesyle for a while, and then noticing that I have absolutely no reason to pull any punches with my opinions.  No affiliations, no politics, no optics to manage.  So why not have some fun expressing those opinions, provocative or not, as DaedTech posts?

Today, I’d like to take on the subject of tech interviews.  Of course, talking about the deeply flawed hiring process isn’t new for this blog.  But I’m going to take it a step further by suggesting how we, as individuals, can try to fight back against Big Tech Interview.

The seed for this came from an idle internet clicking sequence that brought me to a blog.  The company to whom the blog belongs, Byte by Byte, offers the motto, “your one stop shop for acing your coding interview.”  Below that, it says, “master the coding interview game”  (emphasis mine).  It struck me then.  Yes, of course.  It really, truly is a game, and a stupid one at that.  But let me come back to the cottage industry of Princeton Review for tech companies later.

The History of the Job Interview

For this history, I’ll offer an excerpt from my book, Developer Hegemony, describing the history of the job interview in general.

In 1921, tired of hiring college graduates that didn’t know as much as he did, Thomas Edison made up a giant trivia questionnaire to administer to inbound applicants. According to Mental Floss, questions included “Who invented logarithms?” and “Why is cast iron called Pig Iron?” If you look at the sorts of questions that modern day tech companies seem to think they’re cute for asking, courtesy of cio.com, they include such profundities as “Why is the Earth round?” and “How much do you charge to wash every window in Seattle?” If you mixed Edison’s and tech companies’ questions together, you’d be hard pressed to tell the difference.

To summarize, almost 100 years ago, an aging, eccentric, and incredibly brilliant inventor decided one day that he didn’t like hiring kids that weren’t his equals in knowledge. He devised a scheme off the cuff to indulge his preference and we’re still doing that exact thing about a century later. But was it at least effective in Edison’s day? Evidently not. According to the Albert Einstein archives, Albert Einstein would not have made the cut. So the biggest, trendiest, most forward thinking tech companies are using a scheme that was dreamed up on a whim and was dead on arrival in terms of effectiveness.

But surely it’s evolved somehow. Right? Well, no, at least not in any meaningful way. In this piece from Business Insider about the “evolution” of the job interview, we can see that what’s actually changed is the media for asking dumb trivia questions. In Edison’s day, interviewers had to get cute face to face. Now they can do it over the phone, through a computer screen or even via a mobile app. Who knows what the future will hold for the job interview; they may be able to beam the stupid directly into your cerebral cortex!

Google Looks Critically at Tech Interviews

In the book, I cover a lot more ground than I can or will here.  I lay out a case for how uniquely pernicious this interview process is for tech.  It artificially depresses software developers’ wages and manufactures job scarcity in a market where demand for our labor is absolutely incredible.  But let’s seize on a different point for this particular post.

I have specific styles of modern tech interviews in my sights as worse than others.  Specifically, the whiteboard interview, the trivia/brain-teaser interview, and the “Knuth Fanatic,” algorithm-obsessed interview.  These serve mainly to make the interviewer feel smart, rather than to reveal anything about candidates.  But don’t take it from me.  Laszlo Bock, former head of Google HR, said this:

On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.

And also this:

Years ago, we did a study to determine whether anyone at Google is particularly good at hiring. We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess.

Read More

By

The Decline of the Enterprise Architect

Happy reader question Monday, everybody!  Unlike last week (exigent circumstances) and the week before (US holiday), I can actually bring you one on Monday.  I’m trying hard not to pull a muscle patting myself on the back.

Anyway, today’s reader question has to do with the enterprise architect position.  Specifically, what do I think of it?

It’d be great to hear your thoughts on [the enterprise architect], I’m sure there’s more than an article’s worth on that subject.

Simple enough.  So let’s talk enterprise architect.

Prior Art on Enterprise Architects and Regular Architects

I have, in fact, talked about the architect position before.  It’s hard not to when you’ve blogged for as long as I have and as much as I have.  The architect role is almost as ubiquitous as the software developer role.

I once talked about the architect role as a pension plan for developers.  The pyramid shaped corporation creates a stigma that staying “just” a programmer means failure in a career development context.  So even as organizations (mercifully) move away from the “software as construction” metaphor, the concept of architect persists.  It persists because it gives companies an organizationally meaningless way to let someone be “more” than “just a developer.”

I’ve also made posts about the needless division between reasoning about software at a holistic versus granular level and about moving beyond this distinction and the construction metaphor.  These probably weren’t quite as provocative, and they didn’t dive into the toxic role of the pyramid shaped corporation in knowledge work.

But it appears I’ve never specifically talked about the enterprise architect.  Well, let’s do that now.

The Impressive Enterprise Architect

What is an enterprise architect, anyway?  Well, presumably, it’s someone who trades in enterprise architecture, which is like architecture, but more enterprise-y.  Let’s ask wikiepdia.

Enterprise architecture (EA) is “a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a comprehensive approach at all times, for the successful development and execution of strategy. Enterprise architecture applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.”

Wow.  Pasting that into the WYSIWYG made my Flesch Ease of Reading score plummet by 20% as I’m typing this.  That alone probably makes it enterprise-y.  Plus, it plugs in “utilize” as a synonym for “use,” so you know it’s official.

If we unpack — eck, who am I kidding?  There’s no unpacking that rhetorical peacock.  Enterprise architecture is, truly, using a comprehensive approach to practice conducting analysis, design, planning, and implementation to develop and execute architectural patterns and practices that guide organizations through changes related to business, information, process, and technology utilizing various aspects of the enterprise to identify, motivate, and achieve said changes.”

Crap, there goes another 15% off of my readability.  Now only people with tattoos of Gantt charts can read this post.

So what is enterprise architecture, and what, then, does the enterprise architect do?  Well, whatever else they do, they apparently seek to make sure no one ever asks them what they do again.

Read More

By

Automated Code Review to Help with the Unknowns of Offshore Work

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, take a look at CodeIt.Right, which offers automated code review feedback.

I like variety.  In pursuit of this preference, I spend some time management consulting with enterprise clients and some time volunteering for “office hours” at a startup incubator.  Generally, this amounts to serving as “rent-a-CTO” for for startup founders in half hour blocks.  This provides me with the spice of life, I guess.

As disparate as these advice forums might seem, they often share a common theme.  Both in the impressive enterprise buildings and the startup incubator conference rooms, people ask me about offshoring application development.  To go overseas or not to go overseas?  That, quite frequently, is the question (posed to me).

I find this pretty difficult to answer absent additional information.  In any context, people asking this bake two core assumptions into their question.  What they really want to say would sound more like this.  “Will I suffer for the choice to sacrifice quality to save money?”

They assume first that cheaper offshore work means lower quality.  And then they assume that you can trade quality for cost as if adjusting the volume dial in your car.  If only life worked this simply.

What You Know When You Offshore

Before going further, let’s back up a bit.  I want to talk about what you actually know when you make the decision to pay overseas firms a lower rate to build software.  But first, let’s dispel these assumptions that nobody can really justify.

Understand something unequivocally.  You cannot simply exchange units of “quality” for currency.  If you ask me to build you a web app, and I tell you that I’ll do it for $30,000, you can’t simply say, “I’ll give you $15,000 to build one half as good.”  I mean, you could say that.  But you’d be saying something absurd, and you know it.  You can reasonably adjust cost by cutting scope, but not by assuming that “half as good” means “twice as fast.”

Also, you need to understand that “cheap overseas labor” doesn’t necessarily mean lower quality.  Frequently it does, but not always.  And, not even frequently enough that you can just bank on it.

So what do you actually know when you contract with an inexpensive, overseas provider?  Not a lot, actually.  But you do know that your partner will work with you mainly remotely, across a great deal of distance, and with significant communication obstacles.  You will not collaborate as closely with them as you would with an employee or an local vendor.

Read More

By

Pulling Your Team Through a Project Crunch

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and take it for a test drive.

Society dictates, for the most part, that childhood serves as a dress rehearsal for adulthood.  Sure, we go to school and learn to read, write, and ‘rithmetic, but we also learn life lessons.  And these lessons come during a time when we can learn mostly consequence-free.

During these formative years, pretty much all of us learn about procrastination.  More specifically, we learn that procrastination feels great.  But then, perhaps a week later, we learn that procrastination actually feels awful.  Our young brains learn a lesson about tradeoffs.  Despair.com captures this with a delightfully cynical aphorism: “hard work often pays off after time, but laziness always pays off now.”

The fact that we laugh at this indicates something interesting.  Whereas we learn most childhood lessons and internalize them (e.g. don’t touch a hot stove), we don’t learn all of them this way.  Procrastination falls into this latter category.  We learn its perils, but we do it anyway, for various reasons.

As someone in the software industry, I suspect you can appreciate this.  Even if you diligently get out in front of all of your work, your organization may not follow suit.  So I’m sure you’ve seen your fair share of so-called “crunch time” over the years.  Crunch time occurs when you put a disproportionate amount of effort right before an important milestone.  Kinda like waiting until the night before the due date to write a 10 page essay on To Kill a Mockingbird.

Today, I’d like to talk about surviving these crunches.  How can you navigate them to come out on the other end with your team’s morale intact?

Beware the Death March

For argument’s sake, I’ll draw a fine line.  Crunch time and the so-called “death march” can seem like the same thing, but I submit that they differ importantly.  Crunch time involves working hard in a spurt to succeed.  Death marches involve working hard indefinitely with a high probability of failing anyway.

The first step for pulling a team through a crunch is to ensure that you’re not instead dispatching them on a death march.  If your organization has the unfortunate habit of getting itself into death marches, you have serious problems on your hands that transcend the immediate future.  At an organization like this, I’d recommend looking for escape avenues and hinting to others that they might do the same.

If this sounds bad or like the height of disloyalty, I suggest a bit of perspective.  Your organization is about to ask you to burn yourself out on an indefinite timeline for something that will probably fail.  Unless you’re a masochist, what about that warrants your loyalty?

Read More