Posts Tagged ‘software development’

5 Common-Sense Practices Dev Teams Should AVOID

There are a number of common-sense software development practices that can actually hurt your chances of success.

Here are 5 common-sense items you might want to avoid:

1) Treat Team Members the Same

It’s common practice and it makes sense. It’s fair, right? Treat everyone the same. What could be wrong with that?

The origins of the “fairness” practice may come from early childhood when kids discover crying “no fair!” is a great tactic for getting what they want, or maybe it has something to do with the golden rule of “treating thy neighbor as thyself.”

But in practice, we usually do treat our neighbors differently. Some neighbors we hang out with, invite to our houses and party with into the wii hours of the night. Other neighbors we avoid like the plague. So why do we force ourselves to treat all team members the same?

Some team members contribute immensely to the success of the project; they are self motivated, get their work done on-time and get along with everyone. Others, we can hardly count on, they consistently miss self-projected deadlines, they are sick a lot (in the Bahamas) and frequently complain about others.

Why should these two personalities be treated or rewarded similarly? Doing so only reinforces the negative behavior and increases the risk of losing the preferred team member. You have limited resources, both in time and reward-money. If you spread them equally among the team, it’s a disservice to your organization.

You can count on your best team members recognizing that and not tolerating it for long.

2) Follow Established Procedures or Processes

Procedures and processes are there for a reason: to avoid mistakes and to identify the people who make mistakes. Following the rules only makes sense. Avoiding mistakes is a good thing.

Well it might be a good thing, until your best team members start to feel as though their hands are tied behind their backs and if it wasn’t for some stupid process, they would be able to get a task done in 1/10th the time.

Avoiding mistakes is a good thing, but at what cost? Software engineers are essentially problem solvers. That’s what they do all day. The best of them enjoy and derive fulfillment from solving problems with the least amount of effort (both personal effort and computing resources). They are by nature very intelligent people. Every developer on the team probably possesses well-above-average intelligence. They will find ways to solve problems, but if they are bound by some arbitrary rules that prohibit them from deviating from standard procedures and processes, their productivity (and creativity) is limited.

This isn’t to say teams should avoid processes all together. But as a team, there are two ways to view processes: one is to view them as the laws of the land which should be followed at all times and the other is to view them as a set of recommended guidelines that seem to work well, but feel free to deviate as you see fit. The latter is far more productive for intelligent people.

To invoke another biblical adage: The process is created for the team, not the team for the process.

3) Create a Detailed Design Before Starting Development

Seems like a great idea. A detailed design is like a step-by-step instruction list on how to get the job done. Having a detailed design makes the programmer’s job much easier. Nearly brainless. If X is the input, Y is the output. Don’t think about whether or not it makes sense. Just do it.

With detailed designs, you nearly guarantee an increase in productivity and you nearly guarantee a result that’s mediocre at best. Without the ability to refine and adapt a solution as the work is being performed, you eliminate hundreds of branches of potential evolution, which could have made the result that much better.

But having evolutionary branches of a potentially better solution scares a lot of project managers. What if the branches are never-ending and the solutions never get done? That’s a real possibility if the project manager doesn’t do his job well, because a huge part of that job is to help guide the evolution to an outstanding result.

Plus the up-front savings of avoiding a detailed design and opting instead for rough design guidelines will often produce better solutions in less time.

4) Make it Difficult to Change Requirements Mid-way

Project managers are all about delivering their projects on-time and on-budget. The number one risk-factor for delivering a project on-time is a change of requirements.

And, that’s why we have change committees involving numerous people from different departments whose job it is to approve any changes to the established project scope. They analyze the impacts of a change on the project schedule and the budget, often inflating both to increase the likelihood of rejection or at least provide some padding in case the change is approved.

The results are predictable. Changes are nearly always killed by the change committee. Who in their right mind would approve a change that increases the cost of the project and delays the delivery date?

Here’s the big problem with killing nearly all changes: some change is good and by making changes difficult in general, too many changes are killed. It’s a chemotherapy approach of dealing with change…kill nearly everything and hope that the few surviving cells happen to be the ones you wanted to keep in the first place.

That’s definitely one way to do it. But, development teams that employ a democratically-run change committee (1 person, 1 vote) will never create outstanding products. Ideally, changes should be reviewed by teams of 3-4 people, with 1 person having the ultimate say, after considering the input of the committee.

5) Assign Tasks Based on Resource Availability

Gantt charts are a project manager’s best friend as they allow the project manager to view the entirety of the project in a visual representation with dependencies and they can even provide resource assignments. But one of the drawbacks of the Gantt chart (such as Microsoft Project) is that project managers are encouraged to simply assign tasks based on resource optimization and leveling features.

The problem with this should be obvious: important tasks are often randomly assigned to team members based on their availability rather than their skill sets. This is a huge mistake!

Another one of the project manager’s major roles is determining the strengths and weaknesses of each team member and assigning tasks based on this information. Assigning critical or show-stopper tasks to a weak team member is a recipe for disaster. Likewise, assigning trivial tasks to your most talented team members is a waste of your best resources (not to mention a risk of decreasing job satisfaction for those team members).

No Gantt chart is going to identify this information for you. That’s your value-add to the team.

Hopefully by avoiding these common(-sense) mistakes, you can improve your development success. Remember, a lot of the above hinges on the quality of your team, which I wrote about previously. I’d love to hear your thoughts on the above suggestions. Leave a comment if you agree or disagree with some reasons or examples why.

Outsourcing is for Dummies

December 3, 2007 11 comments

Putting Space Between Parts of Your Team is a Sure Way to FailLet’s get one thing out of the way fast: There is no possible way to build and ship quality software on a tight schedule by outsourcing the development, period. If you are in the business of software, then be in the business of software and suck it up and build a team that can write the code. Outsourcing your primary application development is the equivalent of outsourcing the defense of a country. Here’s the primary thing you are admitting when you outsource:

By outsourcing the development of your software, your company is admitting that another company is better than you are at creating the very product that you want to create. You’re also admitting that they can do it cheaper and they can do it better than you can while still making a profit selling it back to you.

If that’s true, then why are you in the business of building software? You should be selling dogfood or cat litter. If you are in the business of selling dogfood or cat litter, then great, continue outsourcing. But even, a company that by any measure is in the “retail” business, builds their own technology and they consider it one of their primary business advantages. If considers it a major advantage to build their own technology and doesn’t outsource its development, then why would you even consider it?

Outsourcing breaks some of the primary laws of building great products. To build a great product, you must have a great team. Notice I didn’t say “you should” or “it would be nice to” have a great team, but rather you must have a great team. A team is inclusive of the designers and developers and testers and trainers and support personnel! If you think that the designers can throw the design over the wall and have the developers give them back a great product, you’re sadly living in a dream world. Although the threshold of importance is substantially reduced with each of the latter items (such as testing, training and support), the quality of those items are also substantially reduced when those items are outsourced.

Lets take a closer look at the most common area of outsourcing: support. Of all the parts of software development, support is by far the easiest to outsource. It requires the least amount of technical knowledge and support managers will often tell you it’s all about “respecting the customer” and “having patience.” So if you can find people in India or Romania who can provide respect and patience to your customers at less than 1/3 the price, theoretically, you should be golden. But anybody who has spoken to a support rep recently from Microsoft, Dell, HP or any other larger tech company who is supposedly saving money by outsourcing support knows from experience that no matter how much “respect” these customer service reps provide, you end the conversation more frustrated than the start, swearing into the air and vowing to never buy from that company again. Of course you end up going ahead and buying from them again because you have no choice, but this time you know, with a heavy heart, that your purchase price doesn’t really include the promised support. Ironically, from the perspective of these companies, their outsourcing strategies save millions of dollars and not just because of the lower cost of labor. The fact that you are less likely to make a 2nd call into an outsourced support center provides an even bigger savings. So here’s what happens when a large company outsources support:

  • Initial costs are substantially reduced due to lower labor costs.
  • Call volume is reduced (due to frustrated users who give up calling) implying that the new call center is doing a fantastic job or the overall support strategy is working great, reinforcing the behavior that outsourcing was the right thing to do.
  • Surveys will reveal nothing because A) nobody fills out 20 minute surveys and B) those who do are almost always complaining, so the percentage of complaints does not appear to be any higher than when the support was in-house.
  • It does not appear that outsourcing support has had any impact on sales. This is, of course, is only a temporary effect as customers often don’t have a choice, but as soon as they do have a choice, it’s over!

So, the outsourcing strategy may initially seem like a success, even while it’s failing miserably. If you can outsource support, then why not documentation or testing? Eventually, why not development? Nobody dares outsource Design. At least not yet. But the metrics are flawed and those who rely solely on metrics for the operation of their business shouldn’t be in business. They’ll get what’s coming to them.

Note that I’m not picking on India or Romania. It would be equally stupid for an Indian company to outsource its software development or support to a US company if labor costs were reversed. I’m also not against outsourcing from the standpoint of “keeping jobs in America.” That’s about the worst possible reason not to outsource. It disrespects humanity and implies that an American’s life is somehow worth more than a non-American. Outsourcing simply doesn’t make good business sense. At least not for a company that wants to be great.

The Optimum Team

At Axosoft, we often move people around, even as little as 20 feet, just to be closer to somebody that they expect to work with on a project. It’s amazing how much productivity can be gained by being next to a person vs. 20 feet away. It encourages conversations and questions about design items, issues, features and things that would have been passed on if the people were simply 20 feet further apart. Having these conversations allows the teams to build a better more solid product in a shorter period of time with fewer defects. Increase the distance by 20 feet and you lower the overall productivity and product quality by some amount. Increase the distance to 20 miles and your productivity and product quality tanks. Increase that by to 10,000 miles and an equally large cultural gap — and you can imagine what will happen. There is a reason why companies like Microsoft, Google and Apple have built corporate “Campuses” that are focused in a single location. The close proximity of all the engineers to one another is a good thing. It creates a healthy feedback loop, which helps increase productivity and increase the overal quality of products and what’s possible. So the optimum team is one who’s physical proximity is as close as possible and its different functions such as design, development, testing and support are not outsourced.

%d bloggers like this: