Archive

Archive for November, 2007

Build Prototypes and Proofs of Concept Early

November 26, 2007 3 comments

Leaving Hardest Part Till the End Might Result in a Puzzle Piece that Doesn’t FitIn any challenging software development project, there are always areas of special concern. These are generally areas that are new and unfamiliar to the team. It could be new AJAX techniques, a new Database backend, Web Services, Javascript, a new UI element, performance issues or a combination of all.But these areas of high risk are often treated just like any other part of the project for estimating and scheduling. Furthermore, the concerns then get shelved until a developer eventually gets to the assigned tasks.

That’s the worst time to fully realize that a planned feature is far more difficult than anybody had anticipated. Sometimes, it’s found that the feature in question isn’t even possible with the current skill set of the team or maybe it becomes obvious that it will affect five other areas of the project (which are now near completion, of course). This will usually cause major scheduling delays and can give the software a non-cohesive feel when it’s finally released.

To demonstrate the importance of the order in which things are done, lets assume you want to build a car. Your team will be building the entirety of the car, including the engine, dashboard, brakes, body, everything! Members of your team have previously built all parts of a car and there’s a ton of experience on board, so you feel confident that the new project will be a success. But, the engine is of particular concern because, except for a few small engines, nobody on the team has built anything even close to the 300HP motor you’re planning for this particular car.If that was your project where would you start? Would you start with the parts that your team are comfortable with or would you start with the engine?

I hope in this example it’s obvious that building a prototype and proof of concept of the engine is the highest priority. If the engine’s size is different than what is expected, it could drastically alter the dimensions of the car, the styling, cabin room, the weight of the car, possibly require different brakes, etc. If the engine runs hotter than you had expected, you might need a different kind of cooling system, larger air intakes causing a different body design or changes in cabin space and overall dimensions again. There’s a lot that depends on the characteristics of the engine. Starting with the engine is essential to the overall success of the project! Furthermore, it’s not possible to estimate the time frame of this project accurately until the proof of concept of the engine is complete.

Now, if your teams biggest strength is engines, you might start elsewhere, confident that your team could reconfigure the engine to conform to limitations imposed on it by other aspects of the project.In software though, most development teams don’t start with the hardest component of the project, which often has the most dependencies. Instead all parts are treated equally. Developers are asked to estimate the project requirements and they simply start development in the order that’s most convenient. Sometimes the order in which things are done is the order in which Microsoft Project’s resource leveling algorithm suggests to get the most bang for the buck. This can leave critical elements of the project for the final weeks or months. By then, the equivalent to the engine might be too big to fit into the body that was designed or it runs so hot that it will melt the surrounding equipment.

To make things work, the top notch quick-thinking team-members generally build additional work-arounds to “make things work” and have the least impact on the project schedule. The end result is software that, at best, is late and doesn’t feel right to end users.

The alternative method of development is to identify key, critical areas of the project that are areas of concern and build those components first. Build prototypes. Create proofs of concept. Test out the team’s theories before committing to a project schedule. If you are committing to a tight schedule for a collection of components that your team has never built before, you’re committing to failure. Don’t leave it to chance, if you want to ship your software on time.

Categories: Development

Building a Great Team

November 12, 2007 6 comments

A Good Team is Critical to Success of a ProjectThe centerpiece of any successful development project is the team that builds it. There is no other single most important contributing factor to building great products. No tools, no development methods, no amount of money and no amount of time can substitute for the importance of an exceptional team if you plan to create an exceptional product.

Some in our industry operate under the assumption “with a good system and a fine-tuned set of processes, you can build anything with a group of average Joes.” If that sounds like your company, congratulations! You must be that average Joe. The assumption that with the right systems and tools, anybody could build great products couldn’t be any further from the truth.

Only driven, motivated and talented teams can make great products. Heavy systematic methodologies of product development and processes can only slow down those teams to ensure that the slowest person on the team can keep up. Process-heavy systems are designed for the weakest team member and therefore must slow down the pace of all other team members to ensure that few mistakes are made by those who are not exceptionally skilled. The cost of such systems is incredibly high.

See if this sounds familiar: Your team is fast at work on the latest project. Due to the size and importance of the project to the company’s success, the executive team is providing the budget necessary to expand the team. It’s estimated that your team will need to increase the “headcount” by 5 or 10, in order to meet its project deadlines. To quickly ramp up for the new required headcount, the bar for qualified candidates falls nearly as fast as the team’s cohesiveness. Within a short time your team successfully adds 10 new “heads” to meet the aggressive project schedule.

To ramp up the new members as quickly as possible, they have been given the proper one-day overview of the project. They weren’t even asked to write code until Day Two. Soon these new team members start contributing thousands of lines of code. Productivity seems at an all-time high. Tasks are getting done in record time and the team now seems to be functioning on all cylinders. If you’re lucky, within a couple of weeks, the first set of problems start to reveal their ugly heads. All kinds of new nasty bugs show up in QA (assuming, of course, that there is a QA team). Senior team members have to take time off of their tasks to track down these nasty issues. After days of searching and going through weeks of code line-by-line, some suspected line code are identified. The first question asked is “who wrote this crap?” and so the process expands.

In order to find out who’s responsible for poorly written code in the future, “checkin” rules requiring detailed comments are put into place.  Additionally, every single line of code is now required to go through a complete and formal code-review to help reduce errors.

The team’s pace changes drastically. Things slow down and soon it’s obvious that the deadline targets of the project schedule are impossible to meet. At current pace, you easily need to increase the headcount by another 5 to 10 to make the ship dates.  But, even that is unlikely as a frustrated, but competent teammember finally speaks up and reminds the executives (and everybody else in the room) that 9 women can’t make a baby in 1 month.

Finally, everybody comes to accept the missed deadlines and the pushed back release dates. Life goes on…slowly.

There is a Better Way

There is, of course, a better way. Among engineers and project managers, it’s common knowledge that a really good engineer can be 3, 5 or even as much as 10 times more productive than a bad engineer. What a load of crap. You’re probably thinking I’m nuts. You might even be thinking that you personally know software engineers who are 3 or 5 times more productive than the guy in the next cube. What you don’t realize is that you are probably discounting their productivity.

It’s possible for a good engineer to be infinitely more productive than the engineer sitting next to them. How is that possible? Consider this: in 1975, how many engineers could have single-handedly done what Steve Wozniak did in designing the Apple I and later the Apple II? What about the search algorithms used by Larry and Sergey (Google)? I know that if you had given me 10 years, it’s not likely that I would have thought of page ranking or search in the way that Larry and Sergey did. So how much more productive were they? I’d say about ($)150 billion times!

The problem with comparing people in terms of multiples of productivity (such as person X is 5 times more productive than person Y) is that there is an underlying assumption that both person X and person Y can do the same job. That is a huge and usually wrong assumption. Two people might be able to do the same job and if one of them is generally 5 times more productive than the other, that probably means there is a whole realm of things that is possible for one of them that’s impossible for the other.

With that in mind, if you were working on a hardware project and estimated that you needed 10 more engineers to get the job done, would you take 10 “Average Joes” or would you settle for 1 Steve Wozniak? If you were working on a Search-related project, would you take 10 “Average Joes” or 1 Larry Page or Sergey Brin? If the answers to those questions seem obvious to you, so should the importance of building a great team. It’s not about “headcounts.” It’s about talent. So to create a winning team, keep a few simple rules in mind:

  1. Hire the most talented people you can possibly find. Don’t hire someone if they don’t meet the bar you’ve set. I know it’s extremely tempting to lower the bar when it’s hard to find good people. Remember that a bad hire could actually have negative productivity!
  2. Create a system that’s flexible and light in process. Implementing any kind of canned methodology that has steps outlined from A to Z on how to create products and manage teams ensures that your team will operate at a low efficiency. A more dynamic and light-weight, low-process system is ideal when your team is already talented enough to know how to do the right things.
  3. Eliminate team members that consistently fall below the bar. Don’t kill them. Just fire them or move them to a different position if you can. If you can’t get rid of team members due to corporate culture or red tape, give them tasks that are non-critical to the success of your project. Often times you can increase productivity faster by removing team members than you can by adding them. If you find that you’re adding process to your efficient system because of 1 or 2 people who consistently need detailed guidelines to get work done, those are the guys I’m talking about.
  4. Create a culture that appreciates talent. Talented people like to work with other talented people. That’s how they’re satisfied. By giving them freedom to do the right thing and taking obstacles (and dumb people) out of their way, you’re creating a culture that appreciates and rewards talent.

By putting the emphasis on the team rather than the process, you’ll create much better products at the end.

Why Software Methodologies Don’t Save Software Projects

November 9, 2007 7 comments

Rigid Systems Can’t Save Software ProjectsAccording to Wikipedia, in Software Engineering, a Methodology is defined as:

A codified set of practices (sometimes accompanied by training materials, formal educational programs, worksheets, and diagramming tools) that may be repeatably carried out to produce software.

Unfortunately, that definition is believed by many, and it’s dead wrong. If you believe it, your projects may be doomed to failure.

Methodologies are systems for the creation of things. A system designed to manufacture cars at Ford or hamburgers at McDonalds is a methodology (although not a software methodology). Ford manufacturing plants produce new cars through an assembly line where each phase of construction is extremely well defined. It’s defined to the point that even robots participate in various phases of construction. You can interchange people who work in the assembly line with relative ease and almost no impact on the end result. There’s quality assurance at every phase to ensure that each benchmark is within the predefined limits. All of this results in the manufacturing of nearly identical cars, in every single instance. It works great.

Likewise, McDonalds has a similar strategy for making hamburgers. The steps to create a burger are well defined. If you change the cook, the burger will still be the same with the same amount of materials, same ingredients, same cooking temperatures, same sauces and the same wrapping. McDonald’s burger-creation methodology results in the customer enjoying the same burger, every single time. Their success is proof that the system works and it works well.

Methodologies Don’t Produce Software

So why not a system for the creation of software? If Ford can do it for cars and McDonalds can do it for hamburgers, why can’t we have a system to produce software? The answer is that we can. The catch, however, is that the system can only re-create software that has already been created. The system cannot produce new software just as Ford’s methodology for creating new cars will never create a different kind of car. It’s designed to re-create the exact same gas-guzzling, poor quality, tire-exploding and boring car in the exact same way that you have come to expect from Ford. So it is at McDonald’s. The system doesn’t create a new kind of hamburger. It simply re-creates the same bad-tasting, low-quality, high-calorie hamburger that you’ve now come to expect from McDonald’s.

In the same light, a software methodology cannot produce new software. This concept is a major surprise to a lot of companies and the US Government, who after spending hundreds of millions of dollars on software projects that end up being canceled — projects that should have been fool-proof in their success. After all, they used the most concrete software methodologies known to man-kind (or to Grady Booch). How could such software projects fail?

Learning that methodologies or well-defined systems and processes can’t create things is important. People create things. Systems and methodologies can only re-create things, but only after people create them first. So what about successful software projects that have employed rigid systems and software methodologies? Easy. Such projects have succeeded in spite of the methodologies used, not because of them and it’s virtually guaranteed that a less restricted team would have accomplished the same task in less time.

New Trends in Software Development

The world is slowly coming to the realization that people are the most important part of any successful new software project. No systems or processes can substitute for your top software engineers. Take your own software projects as an example. Would you give up the top one or two team members or would you give up your software methodology? My guess is that the answer is a no-brainer. Even in a team of 100, losing the top couple of team members would be far more detrimental to the success of the project.

You have undoubtedly heard of new software methodologies such as Agile and Scrum. The popularity of these new light-weight systems is exactly because of the reasons I have explained above. They put the emphasis on people. Is it any surprise that trimming down detailed, process-heavy, software methodologies has produced much better results? Of course not. These new systems are putting the emphasis on individual team members, finally coming to the acceptance that the individuals are far more important in the creation of new software. The systems should only support the individuals, not get in their way. Unfortunately, even these new methodologies are slowly becoming heavy. Scrum is becoming better defined by the day and the more it gets defined, the more Scrum Masters who insist on having a burn-down chart from day 1 on a new project, the more such projects will suffer.

Finding the Right Balance

Like everything in life, there is a balance that each team must obtain between systems and processes and team and individual freedom. Each project is different. There is no one system that can meet the needs of all teams and no single implementation of a system that should be used instead of another. Google’s founders didn’t start with a methodology. Neither did YouTube or FaceBook. Even well established companies like Microsoft and Apple didn’t (and still don’t) have rigid systems in place and they provide significant team freedom to choose the right amount of process for their projects.

So unless you have a lot of free tax-money to waste or if you work on human-safety systems, reconsider the weight of your software methodology. In software, lighter is usually better.

%d bloggers like this: