Incremental Illustrations

Have you ever noticed how an explanation with a whiteboard is often more clarifying than even the most meticulously designed chart or illustration? Even when there is no audience participation, a whiteboard explanation can be immensely more valuable than any professional presentation with the same information. It's certainly not because the chicken-scratch of the presenter on the whiteboard is more understandable. And it's not because the hand-drawn diagrams are more accurate or recognizable. So what is it about a whiteboard that makes the complex so understandable?

Code-Fiddlers

This article is one in a series. See the introduction here.

Everyone is driven by a desire to succeed, but for some, success does not come through superior skill or intellect; for some, success comes through will-power and determination. In the field of software development, such people can often be described as code-fiddlers. There was a time when I looked down on code-fiddlers, but I've since come to realize that they can perform better than me in some ways. To the untrained eye, code-fiddlers are hard to spot. They are able to meet goals and create working products just like everyone else, but we engineers understand the big underlying difference.

Code-fiddlers, you see, don't really know what they are doing. Okay, that's a bit extreme, but at its heart there's some truth to it. They obviously have some clue about programming. They know enough to be able to get their code working, but they don't fully understand why or how it works. You may be thinking that sounds absurd--how could anyone write complex functioning software that they themselves don't understand?! If you are incredulous, let me assure you, it's absolutely true. I have worked closely with many developers over the years that fit this very description. At first, I didn't believe it either. I still don't fully grasp how code-fiddlers manage to pull it off, but I assure you, they do. Perhaps it will make more sense by way of a metaphor...

Making Meetings Count

I've heard it said that there is nothing worse than endless meetings. I almost completely agree. Having constant meetings is exceptionally counterproductive, but to say that there’s nothing worse is to exhibit a slight ignorance. It’s not the worst thing. Having no communication is even worse. So, if both extremes are bad, then what is the proper balance?

I propose that the question is not one of balance, but rather, it's one of quality and kind. If the communication is important, and the most appropriate mode of communication is chosen, then it's almost impossible to have too much of it. The answer is not to focus on how many meetings you are having or how long they last. Rather, the answer lies in making sure that you are only communicating the things that are actually important, and in making sure that you only have meetings when meetings are the most appropriate method for communicating those ideas.

The Average Lifespan of a Crisis

Have you ever asked your team to kick it into high-gear for an extended period of time in order to meet some major challenge?  Let me guess what happened…

They rose to the challenge!   Everyone stayed motivated, focused, and maybe even put in some overtime!  Great strides were made towards completing the goals.  But then after a week or so, that high-gear began to slip.  All that motivation and focus dwindled away.  A few weeks later you looked back and wondered if the project was any farther along than it would have been if you had just kept the status-quo.  

How did I know?  Because it always works that way.  "Why," you ask?  Well, it’s not because all developers are lazy.  Allow me explain.

Hiring by Personality-Type

As I have elaborated in some of my previous articles, the underlying personality of a developer should be of chief concern to you. Depending on the types of products that your team develops, you should have a desired ratio of personality-types among your engineers.  For instance, if you run a contracting service that develops websites for businesses, you will likely want a higher ratio of solution-providers on your team. If you develop pattern-recognition image-processing libraries, you likely want a higher ratio of puzzle-solvers.  Before hiring a new developer, you should seriously consider the type of developer of which you are currently most in need.

Component-Naming Rigor (CNR)

Whenever software engineers are asked to list the most difficult aspects of their jobs, the problem of coming up with good names for their components is always somewhere near the top of the list. Naming components is difficult for the same reasons that naming products is difficult. When you try to find a good name for a product, it can be a significant struggle to find one that is unique within the industry, memorable to the consumers, and yet still meaningful to everyone. Software engineers face the same predicament when naming their software components, but they go through it multiple times a week rather than just once a year. When they create a new class, type, data-structure, or module, they need to give it a name that is unique, memorable, and meaningful. If they fail to do so, they will not only confuse other developers, but they will even confuse themselves.

Embracing Inaccuracy

Perhaps nothing in our industry is more debated than time-estimates. Engineers hate time-estimates because they are never accurate, but everyone else desperately needs them. This tension has spawned a glut of software-development methodologies. At their core, most methodologies are all trying to tackle the same problem: time-estimates. Methodologies either claim to improve the accuracy of your estimates or they claim to lessen your dependency on estimates.

I'm not an expert on all of the various methodologies, but I do know one thing--everyone desperately wants to solve this problem. Everyone is willing to bend over backwards to achieve estimate-accuracy. If someone were able to legitimately solve this problem, the entire industry would immediately adopt the new methodology and its creator would become wildly rich. The fact that such a thing has not happened, yet, tells me all that I need to know. There is no solution, nor will there ever be one. I'm not saying that methodologies are worthless; I'm just saying that you shouldn't expect them to be a silver bullet.

So, should we cease making estimates altogether, as some have suggested? Of course not. That's absurd. Time-estimates are vital to the success of any software shop. So what is the solution? Realism. Don't waste precious energy trying to solve the unsolvable. Embrace the inaccuracy of time-estimates and learn to deal with it.

Rancid-Code Smell

Software, like food, can become rancid. Over the course of time, as new-features are added, adaptations to new technologies are made, and bugs are fixed, all software will begin to show its age. If software is designed well up-front, it will keep for a long time. Even the best designed code requires a fair amount of refactoring, of course, to keep it fresh, but, when it is maintained properly, well-designed code can keep for decades.

As I'm sure you are aware, all-too-often that is not the case. Too often, time is constrained, resources are low, talent is scarce, requirements are flawed, or budgets are tight. Whatever the reasons, most projects eventually become rancid and require either a major re-design or a total rewrite. No one wants to face it, but the truth is, some hopeless projects are even rancid right out of their packaging.

What do I mean by rancid? I mean code that's a waste of time--literally. I mean code that's costing you more time to fix, patch, and improve than if you were to just rewrite it from scratch. But how do you know? How can you, as a manager, determine that a project really is a hopeless cause? You certainly don't want to jump right in at the slightest hint of decay, and start redesigning perfectly salvageable projects. But if a project really is rancid, the longer you delay, the more damage you will cause. Not only will you waste valuable time, but you may also squander precious credibility with your clients as they ask for fixes and all you can offer them is failure after failure. So, again I ask, how do you recognize truly rancid software? What does rancid software smell like?  Here are some common rancid odors to look out for:

Dispassionate-Programmers

This article is one in a series. See the introduction here.

All of the personalities that I have presented thus far have been people who were impassioned in their work. They have been the kinds of people that became software engineers because there was some aspect of the job that they really loved. Most of those people would create software whether they were paid for it or not. That's not the case, though, with the type of developer that I am presenting today. Today I'm going to discuss the dispassionate ones. The word "dispassionate" can evoke some negative connotations, but that’s not the way I intend it. Sometimes dispassion is a great thing and is precisely what you need.

Solution-Providers

This article is one in a series. See the introduction here.

Solution-providers are passionate about what they do, but in a very different way. While the others kinds of developers that I've mentioned care deeply about the inner-workings of the software and how it is structured, solution-providers care about the user experience.

Don't be fooled, mind you; just because they are geared towards meeting the users' needs doesn't mean that they are necessarily good people-persons. Many of them are still the typical anti-social developer that you would hesitate to introduce to clients. It's not their people-skills that identify them as a solution-provider; it's what motivates them that matters.

Solution-providers get thrilled by the problems that their product is solving. They are often the feature-visionaries that dream-up all sorts of amazing things that the software could do. Where other impassioned developers tend to find roadblocks (e.g. "that would take too long", "we'd have to refactor our existing architecture to support it", "it would complicate deployment"), the solution-provider paves ahead full-speed because they are focused on the end-of-the-road. Often, to the shock (and sometimes horror) of the others, the solution-providers are usually capable of achieving their objectives in brilliant fashion.

System-Builders

This article is one in a series.  See the introduction here.

Some people love to build things. It doesn't, so much, matter to them what it is that they are building. The materials don't matter. Even the end result doesn't matter. It could be a tower of wood blocks, or a train-set, or a model, or a house of cards. None of that matters. The thing being built doesn't even really need to serve a purpose. It's the building of it that interests them. It's the manner in which the pieces were expertly placed that excites them--the careful consideration that went into the configuration and placement of each one. If you are ever able to tear them away from their game of Minecraft or SimCity, and ask them what they do for a living, some of them will tell you that they are software engineers. This is the kind of person that I call a system-builder.

Unlike puzzle-solvers, who care deeply about how each component works, system-builders are less concerned with that and far more concerned with how those components fit together.  Where puzzle-solvers thrive on the underlying complexity, system-builders thrive on reducing that complexity.  System-builders don't care about how a particular component was implemented, they are just interested in how they can use that component as a building-block for something bigger.  They appreciate that some puzzle-solver has already invented the quick-sort algorithm, but they have no particular interest in understanding how it works. As long as it already works, they don't want to take time to reinvent it.  They're too busy thinking of different ways that they could use it.

Puzzle-Solvers

This article is one in a series. See the introduction here.

Some children enjoy puzzles.  I don't mean jig-saw puzzles.  I mean things like riddles and brain-teasers.  They love finding solutions to difficult problems.  They are clever.  They think out-of-the-box.  Like many others, they are interested in math and science, but perhaps a bit more so.  As they progress, they become interested in higher-level mathematics and physics.  When it comes time to choose a career, some of these people choose to become software engineers.  When they do, they become a kind of developer that I refer to as a puzzle-solver.

Puzzle-solvers get thrills from taking difficult tasks and inventing the cleverest and least obvious solutions for them.  Puzzle-solvers love things like code-golf and code-obfuscation contests.  They don't just admire low level esoteric languages from afar. If given the chance, they'd use Befunge to solve real-world problems--not because it makes practical sense to do so, but just because they find it fun to prove that it can be done.  They jump at the chance to interpret the meaning of a complex regular expression.

Personality Types - An Introduction

When you compare artists, it's very easy to see their differences.  Even non-artists have no trouble distinguishing between major categories like painters, actors, and musicians.  No one would approach a sculptor and ask them to sing at their wedding reception.  When it comes to software engineers, however, the distinctions are harder for people to see.  It's fairly obvious why, and it's not really a problem, so who cares?  Well actually, you do.  Or, rather, you should.

As a manager of a software engineering team, you need to understand and learn to recognize the differences.  Of course there are the outward things--the learned skills.  Some people are more proficient than others in certain technologies, but that's easy to spot.  I'm talking about something deeper.  Their motivations.  The way their minds work.  Why are they a software engineer?  What do they love about it?