Today, I want to talk a bit about feature creep. Â First off, let me say that I’m going to be performing my own voluntary feature creep in this post by adding a podcast version and a video one. Â Take a look at the next post once it’s up and I’ll do a vid for the both parts (I was just getting long in the tooth by the end of this one).
My programming friends, as well as most engineers I know, already understand the concept, but bear with me. Â Feature creep is a situation in which a scope document was created with requirements before the project started. Â Once underway, however, someone (usually at a higher level, or even a customer level) requests a new feature to be added. Â It may be fairly innocuous, or potentially larger in scale, but in the end, it is another feature that was not included at the beginning. Â One new feature really can’t be considered “creep”, now can it? Â Ok, so the creepiness comes from the fact that it’s not one, but generally, many new features requested, not included in the original scope.
Who Cares? Â That’s What We Pay Them For!
True, you (managers) pay your engineers to complete projects that need to be done. Â And also true, that those features must be super cool if you’re asking for them to be done. Â There are some problems with feature creep though, namely:
- More time is required to implement new features. Â This sounds like a “duh” kind of statement, but for some reason, managers don’t seem to understand that fact. Â Obviously, the engineers are inflating work estimates anyways to get some more time for browsing the internets (yes I pluralized that for fun). Â I have found that in the majority of estimates, these kinds of inflations don’t occur. Â Engineers design the plan and work the plan, basing their estimates on what they really believe they can accomplish.
- More time is required to implement new features. Â Yes, I repeated myself, but this point is slightly different. Â When new features are requested, the engineer generally NEEDS more time. Â This means that the time-table of the project SHOULD be extended. Â I have had so many situations in which features are requested that will take an additional week of work, and the project managers say, “We can’t push the date back.” Â If you go to the store and have just enough money to buy your deodorant, if you pick up a container of ice cream too, some milk and cookies (I’m feeling sweets right now), walk up to the counter and plop it down, the cashier will NOT let you take the items with only enough money for the deodorant that you likely forgot on the way to the ice cream! Â Just because you want more, does not mean you can have it just because you ask.
- More requirements equal more money spent. Â Let’s assume that you can push the date out slightly for the new features. Â That’s great, but what are you really doing? Â You’re increasing the cost of engineering time, obviously, but you’re also increasing testing time too. Â Sometimes, seemingly innocuous feature additions can have some very interesting bugs attached to them. Â So not only are you increasing the engineering time for development, but also testing, bug fixing, and not to even mention documentation of the new features (I’ll assume your customer would want to know how to USE the new feature).
- More requirements can impact system design and robustness. Â Not always is this applicable, depending on the scope of the implemented function, however, systems are designed to perform the tasks they need to perform. Â If you need a simple system that accepts employee hours and comes up with summaries for year-end reports, your design will be MUCH different than if you need a system that will be scalable to incorporate plugins for new functionality that may be needed in the future. Â Or, for example, if your system needs to handle a small amount of traffic by users, it will be designed with one particular database technology. Â If, halfway through, you decide you want to deploy it on a massive scale with millions of hits an hour, that database technology may be insufficient.
Are there more implications to feature creep that I haven’t mentioned? Â I’d love to hear your thoughts!
Update: Check out the sequel: The Dangers of Feature Creep
I presently work in an environment ripe with regulation. The gaming industry (and by that, I do not mean video games for WoW players, or XBOX) is the most regulated market in the world. More so than even health care, in fact. As such, one of our largest points of contention revolves around regulators. These regulators are not one cohesive body, but rather, different entities in every different jurisdiction around the world. This poses some interesting problems with respect to how engineers and managers design products for release. Continue reading “Dealing with Regulators and compromise”
I recently read a post by John Hunter entitled, “Finding, and Keeping, Good IT People,” and couldn’t help but think it merited some additional thoughts on the subject. He makes a few main points in his post, namely: look at the hiring process, reduce your requirement count, treat existing staff well, and a good programmer is a good programmer. I’m going to expand on all of them here.
Look at the hiring process
Your hiring process is intended to filter out the large number of applicants into a small pool worthy of interview. How this process is implemented can turn good engineers off from of a job simply because it is not robust enough to handle the applicants that apply. Continue reading “Hiring and Keeping Good Engineers (part 1)”
So now to the final discussion in my series. About Great engineers! I have been pondering this one, because, for some reason it’s the hardest to provide valuable information about. Great engineers/employees in general are hard-working, deadline-meeting, project-churning machines that bring value to your organization consistently with a smile on their faces. What could be wrong with that?! I’ll guess that nothing is wrong with that, though there is the matter of keeping them as great engineers. Lack of motivation, disinterest in doing the same ol’ thing, frustration with other engineers, and many more daily occurrences can push their productivity down. So for a manager, your job is to ensure that they are happy and able to do their duty!
Without further ado:
Continue reading “Treat Great Engineers Like Gold”
Ineptitude is a difficult issue to combat because there are, obviously, different levels of ineptitude. They range from someone who is selectively disinterested in a specific task (I would argue this is the most frequent), all the way to completely dysfunctional. In the case of the latter, expedient dismissal is the best option. That being said, dismissal is a difficult issue to work with based upon your own organization’s policies regarding termination, and so, I won’t go into detail beyond documentation and getting them out as soon as is practical.
In the case of selective disinterest in certain pieces, however, there are some things you can do to help them to integrate more effectively into the team.
Continue reading “How to Handle Ineptitude”
Assholes assholes everywhere…. ok, not really. I spoke about engineers who behave with utter disregard for anything or anyone but themselves in this post, and now the time has come to elaborate on how a leader can manager these types of individuals. These can be very easy to deal with (for the idle asshole), or incredibly difficult (with the conniving ones), but regardless of how asshole-like they are, here are some tips to deal with them when they are under your employ.
Continue reading “5 Ways To Put Assholes In Their Place”
Update: If YOU are a shy individual and want to get more outgoing, check out this post from Upgrade Reality.
Now that I’ve described the main types of engineers, I’m going to gear some advice in how to work with them. First on the chopping block is those shy and quiet engineers who don’t need, or even want to get noticed, or even talk to others. I think that this category is one of the hardest to deal with because by virtue of their nature, they don’t want to talk to you about problems, improvements, questions, etc.
Throughout high-school, I was constantly berated by my classmates behind the backs of our teachers. I was called many names that I don’t even care to think about to this day, and as a result, I was extremely introverted. I had a close-knit group of 5-7 friends who I would hang out with in my spare time, but for the most part, I would stay at home with my family and watch TV or play on the computer. That all changed when I moved out after high-school with my friend Ryan. He was a jock (baseball player) and therefore had many friends who I had never met and had no interest in meeting. They would come to our apartment and watch TV, play video games, and go off-roading with the group. At first, I felt like my friend was being taken away from me, but as time went on, I realized that these people actually CARED What I had to say! The names never came, and the more I spoke, the more intently I was received. In fact, some of my best friends now, are those who came from his friend-pool and hung out with me! I owe my extroverted nature to that experience. I’m not sure who I’d be if it weren’t for the short 9 months living with him.
Continue reading “5 Tips for Managing Shy People”
So here I’ve been sitting, contemplating how to write this post, and not having any epiphanies as to how to go about it. Shy engineers are easy to discuss, assholes are equally easy. Ineptitude was a bit ranty, though in my defense, those engineers tend to rant of their own accord, so it seemed to fit. Now comes the one that should be easiest to write, but is hard to really come up with something intriguing and useful. So I’m just going to throw it out there for the record, because this is the category in which MOST engineers sit, and the reason engineering actually works in companies. I’m going to refer to them as A+ Engineers because if they were in school, I’d tend to give them all A pluses for grades.
So, without further ado, here is a list of common traits to good, A+ engineers: Continue reading “What Makes a Great Engineer?”
Welcome to the third installment of engineer typologies! I previously discussed shy and asshole engineers, and now I will discuss incompetent engineers. In many areas of an organization, incompetence is something that everyone hates, yet for some reason do very little about. Yes, there is the necessary due process that must come in order to remove someone from an organization, but not always is the situation so obvious as simply seeing someone and removing them. In fact, the type I’m referring to today is that person who comes into the interview before they are hired wearing a three-piece suit, ready and waiting for the questions to begin.
They show you a face that is truly telling of their obvious worth and they have the charisma to back it up. They tell you all of the skills they know they are excellent at, adequately answer all questions posed to them, and then half-way through, you begin to drool (figuratively of course), thinking of the great things you can put them into to gain your team some well-needed clout with upper management. So you hire them. Continue reading “Wanted! Successful Company Seeking Inept Engineers”