EJDC 2006 Conference

I was planning to post this blog from some time.
on 25th I had been to EJDC conference as a speaker and shared my thoughts on Agile best practices and metrics at EJDC Conference. It was supported by Kushal a non profit organization helping poor children in India.

My presentation was mostly towards the best agile practices that are in town and also some of the most popular agile metrics. I got my presentation reviewed by Craig Larman on thursday and got very good suggestions on usage of some of the "terminologies".

Overall I feel the presentation went very well. First half of the conference was devoted to technology related topics(mostly on SOA).

Humane Interface Vs Minimal Interface

I am very new to Ruby(In fact I am trying to understand what it is), and today I stumbled upon an article by ' Martin Fowler ' which is an eye opener for me and I beleive, this could be a good start for me to start visualizing why there is so much hype about Ruby !! I have suddenly started seeing coding in Java/J2EE as x86 programming !!

Traditional "Done" Vs Agile "Done"

I found this interesting post on the web. Here the author williamcaputo is trying to describe the "thinking" of "done" by the traditional team Vs Agile team.


Traditionally 'done' means "We won't have to work on that anymore - and if we do, somebody must've screwed up." For Agilists 'done' means "We have accounted for what is known. If the situations changes, we expect to revisit this work."

Thus the two approaches have different goals: One is to finish, the other is to keep pace with change.

How Idiotic is to track % completion of the project

In recent days, I have been working closely with Craig larman to bring out a new domain modal based on scrum for Valtech cockpit. During the discussion with Craig, he talked about how stakeholders ask for % completion of the project and, how our PMs give them a %(percentage) !! It all looks idiotic if you read the rest of the following section.

The core reason for introducing agile methods in software is to manage the changes, adapt accordingly and be open to get changes. As per the statistics, change requests increases as the project size increases. If we are getting more changes obviously it would add more effort to existing estimated effort and this becomes a moving target. How can anybody estimate how much % of project has completed in this scenario? It is as good as telling not the truth, if I tell my stakeholder that we have finished 50% project !! (Unless you add a clause saying "as of today")

So, instead of using "% Complete" as the measurement, one can use the "estimated effort" remaining to complete the project

What we miss when we talk about TDD

Here is a classic definition of TDD from Agile discussion group,

Classic TDD (and just TDD for that matter) is: write a little example of a (sub)set of behavior, write a little code so that the example works, refactor, repeat.

What we miss all the time while defining TDD is the "Refactor" part !!!

Valtech's global development can lead to world class software development

I was having a chat with Thierry Cavrel while sipping coffee, and we were discussing a host of subjects. In fact, I wanted to share my perspective of how collaborative development can be achieved in delivering quality software at Valtech. Each of the Valtech's units distributed across the world has unique features. Valtech Germany is famous for their technology presence, France for there Project management/delivery capability, India for having expertise in Agile, US for there training and consulting expertise, so on and so forth. Each of these centers have key resources who are making difference. Considering that these resources are used collaboratively, Valtech can deliver any critical project and deliver it successfully.

So, Valtech is a classic example of Global Software development Village !!!

anti-determinism-law

Here is another interesting quote read online (Author: William Bogaerts)

A timeline is going to be difficult, even if you know _all_ the details
beforehand. You know, there is an "anti-determinism-law" in physics
that
says you cannot know both the position and speed of a particle exactly.
There's a similar law in software engineering that says you cannot know
the effort and the requirements together exactly.

Making decisions late in the game

I found the following interesting discussion in the agile discussion forum, and was written by a software developer John: The discussion was about XPs practice "Make the decision as late as possible"

Reminds me of an older paper I recently read (but whose title eludes
me).

According to the premise of the paper, the boundaries that define
components should be drawn based on the difficulty of design choices.

An example might help to illustrate this. Suppose Joe and Harry are
contracted to write a spell-checker.

The customer wants multilingual support, so Joe and Harry agree to use
unicode. This decision is trivial (customer requirement), so there is
no need to abstract the concept of text within the application---they
can use unicode characters and strings.

Now let's say Joe suggests using a map (hashtable) to perform spell-
checking. This seems like an obvious choice to Joe because it makes it
easy to see if a word is spelled correctly. Harry, however, points out
that a map doesn't provide any means of suggesting a corrected
spelling, and recommends a sorted list instead, because it's easier to
find a closest match.

The fact that Joe and Harry didn't come up with the same solution to
the problem indicates the design of the spell-checking algorithm is
more difficult than the question of how to represent text.
Consequently, it's probably a good idea to encapsulate the
spell-checking algorithm, isolating its implementation details from
the rest of the application. This way, if they head down the wrong
path, they can correct their mistake with minimal impact to the rest
of the application.

I agree with this general philosophy. If a design choice isn't obvious
to you, that's because you don't have enough information. If you don't
have enough information, and make a decision anyway, you're more
likely to get it wrong. So in those areas where you can't immediately
(or unanimously) decide, it's best to introduce enough abstraction so
that if you choose poorly, you can correct your mistake without having
to rewrite the whole application.

Elephant looking from various directions

I found this interesting piece of information on the agile forum by a member (Philip, no last name). This is what I always preach when somebody asks me the relation. Also, it is in synch with my thought that Agile is spirituality rather than a religion !!

All the agile processes use automated tests and frequent releases.

All the books about Agile development represent consultants telling
specific teams what to do, and making up jargon. They are all blind
men groping the same elephant, but each has named their part of it
something different. It's all the same elephant.

Crossing the chasm

I found this nice article on Dr.Dobb's portal, which talks about companies based on their ability to take risk and move towards agility.

http://www.ddj.com/dept/architect/187200223;jsessionid=4MASEABOIHHWYQSNDBCCKH0CJUMEKJVN

Pros and Cons of using Index cards over computer

Agile proposes people to make use of Index cards during requirement analysis and estimation phases. As per agile, it would help the development team and other stakeholders to change things quickly, ask questions without really "handing off" documents and waiting for things to happen.

Here are some of my thoughts on pros and cons of using 3*5 Index cards:

Pros:
1. Very agile. You can modify the information with ease.
2. Sticking them to the wall keeps the information in front of your eyes all the time.
3. Easy to carry from one place to other.

Cons:
1. Chances of getting lost are high
2. You may need a good secure storage space. Because over a period of time, the paper might become old and the chances of paper getting torn, and information getting lost is high.

One of the key advantage of using Spreadsheet(in parallel with Index cards) are
1. Quality of information would stay intact over a long period of time.
2. Sharing the information with onsite team located in a distributed team is easy
3. Spreadsheet is idea to keep track of information which keeps changing quite frequently.

Insert more bugs by working late hours !!!

Here is what Ron Jeffries says about the impact of working late hours, and how this could result in programmers inserting more defects :

If the risk of an accident is essentially doubled at twelve hours compared to eight, what about the risk of inserting bugs? By the time a measurable accident occurs, the worker has probably been fumbling around, working erratically, for quite some time, and finally got so far off track that an accident was the result. My educated guess would be that the insertion rate for defects increases far more rapidly than the risk of industrial accidents. What the accident statistics probably tell us is that a tired programmer has double the chances of putting in a very serious bug, but has probably also put in a much higher percentage of smaller ones.

A recent Circadian study addressed productivity in white collar workers. They found that even as little as a ten percent increase in work hours could result in a 2.4 percent drop in productivity, while sixty hour weeks could result in a 25 percent drop in productivity.

Blogger for dummies

Found this interesting link for dummies: http://bloggerfordummies.blogspot.com/

It is really cool

Change request in XP

Dave Rooney wrote the following on handing change requests in XP:

A change is simply another Story or Stories, so use new cards. They can be estimated by the developers and prioritized by the Customer. During Release Planning, we've filled the iterations based on the team's velocity. So, in order to schedule a new story into an existing iteration, a story or stories of equal size must be removed. There's no 'We'll squeeze it in', or 'We'll try to get it done'. When you do that, the developers will start to fall off the testing bandwagon in a hurry. Then, the system's quality goes out the window. The key point is that time is not variable, but scope is."

Documentation in agile

In one of the agile discussion forums following question was asked and the answer made sense to me(in bold)
>I have tried to limit documentation and verbally brief my >engineers on what I want doing - normally a white board >discussion. Ask them to work in pairs, keep documentation to a> minimum and get every one to understand the design by >verbal communication.

Limiting documentation isn't the world's greatest idea. It's better to let them figure out what they actually need and what's a waste of time."

User Stories and What they are in "Simple terms"

A Very good explanation from the Mayford technology website :

A User Story is a short description of the behavior of the system from the point of view of the Customer. They are in the format of about three sentences of text written in the Customer’s terminology without technical jargon. In simplistic terms, user stories are the response to, "Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two."

The conversation takes place during Iteration Planning, at which time the Programmers ask questions of the Customer in order to flesh out the details of the Story, and then brainstorm the Tasks required to implement it.

Typically, the stories are written on 3" x 5" index cards, although an electronic copy may be used. Since index cards are somewhat small, they automatically limit the amount of writing that can be put on them (which is a good thing). This forces the Customer to focus on making the text clear and concise, while being as simple as possible.

Story cards are a great conceptual tool. When they are laid out on a table, the Customer can visualize the entire system. Since the cards can be easily moved around, the Customer can 'see' the system from different perspectives. They also work well during development, providing a very concrete reference to how much has been completed, and how much work is left.

Once the Stories have been estimated and the initial Project Velocity set, the Customer can make tradeoffs about what to do early and what to do late and how various proposed releases relate to concrete dates.

There has to be at least one story for each major feature in the system, and it must always be written by the users. The programmers shouldn't write the stories, but they have conversations with the users that are then attached to the stories together with pointers to supporting documentation.

Different than Requirements

A typical misunderstanding with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the Customer and receive a detailed description of the requirements face to face.

Another difference between stories and a requirements document is a focus on user needs. Details of specific technology, data base layout, and algorithms should be avoided. Stories should be focused on user needs and benefits as opposed to specifying GUI layouts.

How z user story different from use Cases ?

One approach that has been suggested is to define the Stories during the Planning Process, and then create a Use Case for each Story at the beginning of an Iteration. This allows the deferral of specifying the details of a Story until they're really needed. Some would argue that Use Cases aren't really needed, although it may be a requirement for your organization. At any rate, Stories and Use Cases aren't mutually exclusive.

Lean Manufacturing and Software

A Nice article on lean Software Development:

Lean Manufacturing and Software: "Value and Waste

A good starting point is to consider what value is, and what waste is.

What are things with value?

* Raw materials
* An end product that someone is willing to buy
* Tools used by the team
* The skills acquired by the team

What about intermediate products? They have some value in the sense that they give us the option to create the final product more cheaply than if we started from the beginning. They have no value if nobody is willing to buy the end result. And intermediate products clearly have a cost.

And what is waste?
If it doesn't add value, it's waste.
--Henry Ford

Waste – anything other than the minimum amount of equipment, materials, parts, space, and worker's time, which are absolutely essential to add value to the product.
--Fuji Cho, chief engineer at Toyota

Taiichi Ohno is known as the father of lean manufacturing, and he identified seven types of waste. We'll consider them and find an example of each applied to software:

Waste


Software Example

Overproduction


Features that nobody ever uses.

Waiting Time


QA waiting for a feature to be written so they can test it.

Transportation Waste


Time waiting for files to copy.

Processing Waste


Software written that doesn't contribute to the final product.

Inventory Waste


A feature for which development has started, but nobody is currently working on it.

Wasted Motion


Doing a refactoring manually when the development environment can do it automatically.

Waste from Product Defects


Bugs.

Ohno talked about a diagram of a boat that represents the pipeline translating raw materials to a finished product, traveling across the sea of inventory. Every waste in the system is like a hidden rock at the bottom of this sea, which may be a hazard to travel over, and which raises the level of the water and makes the boat travel further.

To make these rocks visibl"

Cost of Change Model

I found this nice article on henric.vrensk.com website !! It explains about the cost of change and how it can be controlled through agile process.

Exponential Cost of Change model, sometimes known as the Boehm Cost of Change Model, states that the cost of changing software increases exponentially with time. This is often expressed as "if it costs €1 to make a change in the definition phase, then it will cost €10 to make the change during design, €100 during coding, and €1000 after the software has been delivered.
This model has had a profound impact on software methodology: if change is caused by defects in the software, and if the cost of fixing a defect rises this dramatically, it makes sense to prevent defects from occurring at all. This is why rigorous methodologies 1 recommend that a lot of effort is put into gathering requirements and doing as much design as possible before coding starts.

This model meshes well with traditional engineering knowledge in other disciplines. For example, if you are an engineer responsible for building a bridge, you don't want to be told to move the bridge just a little bit to the left, when three quarters of it has already been built. Manufacturing industry has used a similar exponential model to estimate the cost of making changes since the early 20th century.

This model seems so self evident that for a long time very few people questioned it. When software projects went wrong it was a natural assumption that not enough effort had been spent gathering requirements and designing before coding started.

Amazingly, Highsmith is right. Boehms data indicates a cost increase of 20-40 times for a typical large well run project, with an almost flat curve for the best ones. This is far from the 100-1000 times increase most people believe Boehm's data indicates. On small to medium size projects (projects with 50 people or less), which is by far the majority of all software projects today, the curve can be expected to be even flatter than on a large project, which is exactly what Kent Beck and other agilists claim.

Boehm's work also shows that it is possible to change the shape of the curve through good management practise. This is conceptually different from the rigorous methodology view that the curve is fixed and that management practises must adapt to it.


Cost of Change, Part 1: Dispelling Myths

Ultimately, the most important reason to use a software development methodology is to make as much money as possible. Even though we don't always think of it in those terms, every software development methodology is based on an economic model. The dominating economic model since the seventies has been the exponential Cost of Change model, usually attributed to Barry Boehm. Until the mid nineties, this model was rarely challenged. Over the past ten years there has been a mounting body of evidence that contradicts the exponential model. This article explores the exponential Cost of Change model, its main competitor, and the importance of choosing the right model as basis for software development.
The Exponential Cost of Change Model

The Exponential Cost of Change model, sometimes known as the Boehm Cost of Change Model, states that the cost of changing software increases exponentially with time. This is often expressed as "if it costs €1 to make a change in the definition phase, then it will cost €10 to make the change during design, €100 during coding, and €1000 after the software has been delivered."

The exponential Cost of Change curve, used as the economic basis for most current software development methodologies.

This model has had a profound impact on software methodology: if change is caused by defects in the software, and if the cost of fixing a defect rises this dramatically, it makes sense to prevent defects from occurring at all. This is why rigorous methodologies 1 recommend that a lot of effort is put into gathering requirements and doing as much design as possible before coding starts.

This model meshes well with traditional engineering knowledge in other disciplines. For example, if you are an engineer responsible for building a bridge, you don't want to be told to move the bridge just a little bit to the left, when three quarters of it has already been built. Manufacturing industry has used a similar exponential model to estimate the cost of making changes since the early 20th century.

This model seems so self evident that for a long time very few people questioned it. When software projects went wrong it was a natural assumption that not enough effort had been spent gathering requirements and designing before coding started.
The Challenge

There was one little problem: despite ever increasing efforts to gather requirements and make design up front, software projects kept failing with alarming frequency. The theoretical model and reality just did not match.

In the year 2000 a well known industry profile wrote a book that challenged the exponential cost of change model. The book was Extreme Programming Explained, and the author was Kent Beck.

Beck claimed that the exponential curve was no longer valid. He claimed that with a combination of technology and programming practises the shape of the curve could be changed. The shape change, he claimed, could be dramatic. Under the right conditions, the Cost of Change curve could even be asymptotic, i.e. it flattens out so that the cost of change hardly rises at all throughout most of a development project.

Beck's asymptotic Cost of Change curve.

Becks's claims went contrary to established ideas. It was like being told that the Earth revolves around the Sun, when you have always believed it is the other way around. It was hard to ignore Beck, or dismiss him as a loon. He was well established in the field, a pioneer in the field of Design Patterns, co-creator of Class Responsibility Collaboration (CRC) cards, a well established software design tool, and he had the support of industry luminaries like Erich Gamma, Ward Cunningham, and many others.

Beck's book paved the way for a new breed of software development methodologies, the Agile Methodologies. The Agile movement had existed for some time when Extreme Programming Explained was published. The book got the agilists attention outside software conferences and elite software companies. A flood of other books, describing Extreme Programming, other Agile methods, and the basic principles of Agile software development, followed. Project teams, and companies began to openly declare that they were using Agile practises. Today, Agile methodologies have a well established hold among early adopters, and is well on its way into mainstream software practises.

There are many Agile methodologies. One of the things that they all have in common is the belief that the Cost of Change curve can be altered through technology and sound development practises.
Competing Belief Systems

So far, I have described the two competing economic models as belief systems, without much regard to their conformance to reality. Of course, the Agile methodologies, and their underlying economic model, was born out of dissatisfaction with the methods based on the exponential Cost of Change model, but this does not prove that the economic model itself is at fault.

To better be able to judge the relative merits of the two systems, it is helpful to look into their history. Under what circumstances did they emerge? Who created them? Does either of them have a sound scientific basis?
History of the Exponential Cost of Change Model

In 2002 , in the book Agile Software Development Ecosystems, author Jim Highsmith made an astounding claim: the Boehm Cost of Change model does not exist, and it never has. A gigantic misunderstanding has shaped software methodologies for three decades.

Would the software industry bank all their money on an economic model that is just a figment of the imagination, for decades? Can't happen! Outrageous! Nevertheless, Highsmith got support from the most unlikely of sources, Barry Boehm, supposedly the originator of the exponential Cost of Change model.

In 1976 Boehm published an article in IEEE Transactions on Computers that presented data on the Cost to Change rate gathered from TRW, and corroborative data from IBM, GTE, and Bell Labs Safeguard program. This data is also in Boehm's book Software Engineering Economics, from 1981.

Highsmith went straight to the source and contacted Barry Boehm to ask him about the data, and Boehm's interpretation. Boehm's data indicated a 100:1 cost growth on large projects, if they were badly run. It was also possible to identify and classify about 20% high-risk defects that caused about 80% of the cost of rework. Using this information, it was possible to change the shape of the Cost of Change curve. In an email to Highsmith, Barry Boehm stated that On our best early ´90s projects, this lead to fairly flat cost-to-fix-curves. In other words, the best of the large projects using Boehm's method in the early ´90s, had the flat curve Beck claimed to be able to achieve with more consistency for small projects in 2002.

In reference to a later study, Boehm noted that large projects with risk management, where attention was also paid to architectural issues, usually had a cost growth of between 20:1 and 40:1.

Boehm's data indicates that defect prevention is certainly worthwhile. On the other hand, Boehm never made the assumption, or drew the conclusion, that most changes are due to defects. The rigorous methodologies, on the other hand, tend to assume that nearly all changes are due to defects, either in the software, the design, or the requirements process.

In 1987 Boehm introduced a spiral, risk driven, change tolerant, management model that is designed to mitigate costs over the entire life-cycle of a project. In other words, the Boehm Spiral Method, as it is called, seeks to prevent unnecessary defects, but also strives to accomodate changes due to other reasons, such as changing requirements.

Amazingly, Highsmith is right. Boehms data indicates a cost increase of 20-40 times for a typical large well run project, with an almost flat curve for the best ones. This is far from the 100-1000 times increase most people believe Boehm's data indicates. On small to medium size projects (projects with 50 people or less), which is by far the majority of all software projects today, the curve can be expected to be even flatter than on a large project, which is exactly what Kent Beck and other agilists claim.

Boehm's work also shows that it is possible to change the shape of the curve through good management practise. This is conceptually different from the rigorous methodology view that the curve is fixed and that management practises must adapt to it.

How can the popular conception Boehm's Cost of Change model be so different from the reality? Probably because most managers are familiar with the 1:10:100:1000 rule of thumb from engineering and the manufacturing industry, and they just assume the same is true for software development. Old ideas die hard, it is as simple as that. It was a long way from Galileo proving that Earth orbits the sun, to people in general believing it.
History of the Flat Cost of Change Model

Beck's flat Cost of Change curve didn't just spring into existence one day. The idea that costs can be mitigated during the course of a development project has roots that go back quite a while.

Central to object oriented programming is the idea that if different parts of a program can be built so that they are independent of each other, then the parts can be changed independently of each other when the need arises. This is a way of mitigating the Cost of Change late in a project. Adding or changing an independent part costs no more the week before delivery than it does the first week of planning. For example, adding a new printer driver to an operating system can be done late in the development cycle without incurring extra costs. (Given of course that the resources to develop the driver are available.)

The first object oriented language was Simula-2, designed in the ´60s. In the early ´80s the language Smalltalk was made widely available. Smalltalk programmers are credited with either inventing or promoting many important programming concepts. In 1987 Kent Beck and Ward Cunningham used Smalltalk to experiment with design patterns, a concept they had borrowed from building architect Christopher Alexander. Today, design patterns are ubiquitous in object oriented software design.

Beck, as a design pattern pioneer, was of course well aware of the economic implications of using object oriented programming languages and designing loosely coupled software. So did many other people that were working on their own Agile methodologies at approximately the same time.

The agilists also had inspiration from sources outside the software industry. In the late ´40s and early ´50s the Japanese worked hard to recover from WWII. At the time, Toyota wrestled with the problem of how to compete with American car companies that had vast resources and higly optimized mass production systems. They did figure it out, and created a system that would become world famous, the Toyota Production System. The Toyota Production System inspired Lean Manufacturing, and the practises and ideas of Lean Manufacturing found its way into the world of software development in the form of Agile methodologies.

It took twenty years for Lean Manufacturing ideas to gain a foothold in manufacturing industries outside of Japan. Even today those ideas are often very poorly understood in the west. It should not be a great surprise that it wasn't until the ´90s that those same ideas made the jump to the software industry, or that they are still poorly understood today.

Lean Manufacturing, and Lean Software Development, are complex methodologies, and their parts cannot be readily understood in isolation, no more than you can understand how a complex program works by studying a single class. Nevertheless, I have picked a few ideas that have a very direct bearing on the Cost of Change, and that are worth describing:

* Options Thinking
* Last Responsible Moment
* Cost of Delay
* Refactoring
* Testing

The same ideas recur in various Agile methodologies, sometimes under different names, and in slightly different contexts.
Options Thinking

Options Thinking is a technique for delaying irreversible decisions until uncertainty is reduced. Options thinking is common in the financial and commodities market, where an option is the right, but not an obligation, to buy stock in the future. Options thinking means keeping as many alternatives as possible open as long as possible. Decoupling software components keeps options open. So does training developers in many different skills, so that they can solve many different types of problems.

Options Thinking reduces complexity by delaying decisions until as much information as possible is known. Rigorous methodologies do exactly the opposite, they try to reduce complexity by limiting the number of options as early as possible. Experience from the manufacturing industries indicate that when these two systems of decision making compete in complex and dynamic situations, Options Thinking wins out in economic terms. The risk is lower, wasteful effort is reduced, the decisions are better.
The Last Responsible Moment

The Last Responsible Moment is the last moment when it is still possible to choose between options. Delaying a decision beyond that is procrastrinating. Acting at the last responsible moment is akin to when a karateka (karate practitioner) punches just at the moment when an opponent prepares to attack. Until the moment of the punch, the karateka manouvres to keep as many options open as possible. If the karateka misses the crucial moment, the he will have lost the initiative, and will be forced to respond to events instead of initiating them. Delaying commitment to just the right moment is a game of tactics, and agilists have an array of techniques at their disposal. Some rigorous methodologiess, like RUP, use many of the same tactics as part of the design process. The difference is that the techniques are thought of as software design techniques only, and not as management tools. (Some of these techniques will be described in a future article.)

It is worth noting that some decisions will have to be made early on. This is one of the points were Boehm and the agilists are in agreement. For example, automated unit testing works best if it is used from the start. Refactoring must be a part of the development method from day one for maximum effect, and a build machine should be ready for use when coding starts. Committing to a particular database implementation, to the exclusion of others, on the other hand, is a decision that can often be deferred forever, by using a suitable Object Relation Mapping (ORM) framework.

Options Thinking is an important factor in flattening the Cost of Change curve, but it must be combined with the skill to identify and act at the Last Responsible Moment, or defeat will be snatched from the jaws of victory.
Cost of Delay

Most rigorous methods assume an even tradeoff between development time and development cost. Halve the development time, and you halve the development cost. Double the development time, and you double the development cost. This is a comfortably simple model. Unfortunately, in most cases it is wrong.

When starting a software project, it is possible to create a simple economic model, a Profit & Loss Statement, that shows the expected economic benefit of the project. The Cost of Delay can then be calculated by adding a time delay to the model. In most (but not all) cases, the delay will have a much greater impact on profitability than just the cost of development. Time to market is usually the crucial factor. This is true even for software applications that are for internal use only, such as an economy system, intranet web site, or document management system. The earlier the system can be used, the earlier the company that uses it can start reaping the economic benefits, even if the system has only partial functionality at first.

The upside is that if time to market can be reduced, for example by making an early release with reduced functionality, this will often have a great positive effect. It is not uncommon for a development project to pay for itself during the development time, if it can make an early delivery with partial functionality, followed by frequent partial releases. This is the reason for the Extreme Programming mantra "release early, release often".

The Cost of Delay has a direct impact on management decisions. For example, if the developers want a tool that will reduce development time, the tool may be worth buying, even if it costs more than the direct cost of the development time saved. Conversely (and perhaps more common) forcing developers to use tools that are poorly suited to a particular job to impose a corporate "standard", is a far more expensive undertaking than the management would ever imagine.

Understanding the economic effects of delays, and time gains is an important factor when minimizing the total cost of a project. There is also an impact on the Cost of Change. For example, it is possible to model the cost of feedback delays imposed by different testing strategies. Which is most economical, having a test phase at the end of the project, test at the end of an iteration, or use automated tests that run every few minutes as part of the development cycle? With an understanding of the Cost of Delay, it is possible to construct an economic model and come up with the correct answer.

Refactoring

Refactoring is a technique for improving the quality of code without changing the functionality. Many managers shudder when developers tell them they want to refactor code. Why spend effort "beautifying" code that already works? It must be a waste of time and money. Wrong! The managers should rejoice instead, because the desire to refactor code shows they have a team that understands the detrimental effects of letting bad code remain in a system. And yes, the detrimental effects are "detrimental economic effects".

In most projects code quality deteriorates rather rapidly over time, even if the code works. What does this mean? It means:

*

The code is tightly coupled, so changing one part of the system causes a cascade of changes in other parts of the system.
*

The code is unnecessesarily complex:
*

There may be hidden bugs that will strike when least expected, for example after the system has gone into production.
*

Every time a developer reads the code, he must spend extra time and effort understanding it. This can cause serious time loss, because even though a piece of code is written only once, it is read many times during a development project.
*

Important cross-cutting functionality, like error handling, logging, and security management may be poorly implemented, or not implemented at all. At best, this slows down both implementation of new features, and changes to existing ones. At worst, it may stop a system from going into production.
*

Performance is poor, often due to unnecessary database accesses, poorly implemented search or sorting routines, the wrong choice of technology (for example parsing XML with SAX when DOM is better, or parsing XML with DOM when SAX is better), and so on. Poor performance in a system means reduced profitability, sometimes to the point where the system ends up costing more money to use than it saves.

Poor code quality may not be noticeable to a manager at first, but eventually it makes a project leak money like a sieve leaks water. Refactoring is a primary method of plugging the leaks. It is an important tool for bending the Cost of Change curve from the exponential disaster-in-waiting shape to the flat curve of a well managed project.

Reviewing Software Programmers

Nice Article on Reviewing software Programmers

http://home.att.net/~geoffrey.slinker/maverick/MaverickReviews.html

Hiring Software Programmers

Nice Link about hiring Software Programmers.

http://home.att.net/~geoffrey.slinker/maverick/MaverickHiring.html