636375 1994-06-04  18:44  /256 rader/ Ulf Lagerstedt
Mottagare: Programmering (-) algoritmer (och) liknande <1513>
Mottagare: Programutvecklingsmetodik (diskussion & erfarenhetsutbyte) <12>
    Sänt:     1994-06-09 02:26
    Sänt av Fredrik Nyman  (statstjänstefnask)
Markerad av 17 personer.
Ärende: Hur man driver utvecklingsprojekt
------------------------------------------------------------

Denna artikel är från Software Development International, vintern 1991. 
Läs den.



		Writing exceptional software

It may be surprising to most people that there is no great secret to
developing exceptional software. Exceptional software is almost always
developed quickly by small teams of developers. More than 80% of the
top-selling PC programs were developed by one or two people. 

The typical method of doing business works well for many products. It
includes extensive planning and a methodical, traditional management
style. But it's completely ineffective in a software development
environment. The following changes are necessary to encourage superior
software development.

Most importantly, individual developers need to be given total
responsibility and control for their parts of a program. Each
programmer should be responsible for designing, coding, and debugging
a specific part of a program, and be encouraged to use his or her own
judgment as to how each part should appear or function. 

When a developer working for me told me I was wrong about and approach
I had suggested, I would try to learn the reasons and work out a
compromise. However, if we could not reach an agreement, the developer
almost always had the final decision.

No programmer should be split between several projects. People will
work diligently and effectively to finish a single product. They will
not work nearly as well if they are being pulled in seven different
directions at once.

Each programmer should have a sense of ownership of their part of a
program. If a person owns something and has control over its success,
that person will work hard to make it as good as possible. This is a
big change. Working a certain number of hours to finish a certain task
is no longer a programmer's job. Instead, programmers develop a piece
of software for which they are solely responsible: from design and
coding to testing.

A programmer is told what and how to code. A developer determines what
to code and does it independently. Companies that hire programmers
write bad software. Companies that hire developers write superb
software. Quite simply, programmers must be turned into developers.
When this change occurs, the increases in productivity, innovation and
quality are incredible.

When I started one job as director of software development, the
company had a project involving six programmers, that had been in
development for over three years and was 25% completed. One person
specified a section. A second person designed it and broke it into
server, client and fourth generation language parts. These three parts
were given to three different programmers to develop independently.
Finally, another person would test the programs.

Not only was almost nothing getting done, but the programmers had
realized a year earlier that the fourth generation language would not
work in the final user environment. But they kept using it. These were
intelligent people who cared about finishing the project. However,
they were placed in a situation where they could not succeed. 

My first action as director was to have the group break the project
into six major pieces and assign each person one complete part. Each
developer was totally responsible for a piece of the project. One
quarter of the project was completed in four months.

Don't worry about consensus. Most software programs can be written in
three to six months. If you don't write it that quickly, someone else
will. If you take the time to study, arrive at a consensus, and
completely design a product, the people who just sat down and started
programming with only a general plan will probably have been selling
their product for several months by the time you get to market.

Time is the second greatest enemy of software development (bad
management being the first). If a new product beat its competitors to
market by six months, it will most likely dominate that market. Any
product more than 18 months old will start to lose large amounts of
market share if a good update does not come out quickly.

Developers must be free to try ideas that others don't like. When I
was developing a litigation-support system for attorneys, I developed
a menuing system that *everyone* disliked. However, I believed it was a
good interface and kept it in. When the product was finished, everyone
who used it (including earlier detractors) thought the menu interface
was the best they had ever used.

Group consensus generally does not contribute to good software design.
The specification for the Ada compiler was designed by the U.S.
government and a number of big companies. No one uses it unless
required to by government contract. On the other hand, C was designed
by two developers and is now used in more than 85% of the software
developed in the U.S. for PCs. 

Eliminate project design and review as an exhaustive and rigorous
process. A project proposal should be less than one page long and
preferably only a page or two. Anything longer mires the project in
bureaucracy before it starts. Most design should occur as the program
is written. 

Minimal, formal, ongoing reviews of a project should be conducted. At
four to six months, the basic program should be working. Look at it
then and determine if it makes sense to continue. At the end of an
additional four to six months, the project should be completed.
Monitor progress by talking to individual developers as the program is
being written. 

You must trust the developers on the project to create a good product.
If you review each step, developers no longer have control or
responsibility and become just programmers again. Also, developers
spend so much time in meetings that almost no time is left to program.

You will occasionally have failures using this method. However, the
successes will be so much greater and quicker that the net, positive
result will be worth it. "Fast failure" is expected to occur many
times. When it does, you find a new way to solve the problem. The
important thing is to fail quickly so you have time to find another
approach. 

Developers must also feel free to say what they think to their
supervisors. Constant feedback is essential for developers to be able
to test new ideas and for management to know what is happening.
Ideally a free market will exist: all ideas are brought forth and the
good ones survive.

A software project manager should be one of the program developers.
The majority of the manager's time should be spent designing and
writing part of the program. The remainder should be spent talking to
others on the project to make sure its going in the right direction.

The manager must be a very good programmer in his own right. A manager
who is less capable than the developers cannot possibly follow what is
happening. I do not know of a single successful software company where
the individual in charge of software development is not a superb
developer. 

Finally, no project should take more than six people or longer than
one year - no exceptions. Adding more people, especially late in the
game when the project has gone past schedule, just slows it down. It's
not just that the seventh person adds little productivity to the
group, but the seventh person reduces total group productivity. 

If Volkswagen needs to produce more cars, it doesn't put more people
on the assembly line; it builds another assembly line. An assembly
line with too many people will produce fewer cars because people will
get in each other's way.

Assigning too many people to a project essentially guarantees that you
will turn everyone into programmers and the project will take several
years. I do not know of a single project with more than 10 people on
it that was completed in under a year. I know of many comparable
projects completed in less than six months with one to three
programmers.
 

Compensation must be based on the developer's skills. Age, schooling,
and number of years with the company are irrelevant. You hire
developers because you want them to write superb code. If they can do
so, you should pay then a superb wage. One of the best developers I
know never went to college - it is not a factor in his salary.

Also, overtime should not be paid. Developers are paid to develop
software and their compensation should be based solely on how well
they develop it. If one person works twice as many hours as another
but both complete comparable projects in the same amount of time, they
should be paid the same. If someone is paid overtime for working long
hours, even if they get nothing done, then you are giving the message
that the appearance of work is more important than the actual work
produced. 

If someone who does and efficient job is paid the same (or even worse,
less) than someone doing a mediocre job, you are telling that person
that their development abilities are not important to you. In the
U.S., good programmers make more than $50,000 a year and excellent
programmers, more than $100,000 a year. Programming geniuses, and there
are a number of them, can make more than a million dollars a year.
These people are paid well and earn their money. They are the ones who
produce software that sells millions of copies and makes millions of 
dollars. 

A significant portion of each person's compensation should be made in
bonus or profit-sharing form, based on the merits of their projects.
This kind of renumeration gives developers extra incentive to complete
their projects quickly and deliver a superb product.

Remember that an employee's pay is the truest measure of the value a
company places on that employee. No matter what you tell employees,
they will not have much loyalty if they are poorly paid. In addition,
if a developer is good enough, some other company will make a
worthwhile offer. 

The most important part of the work environment is flexible time.
Developers should be able to work the hours they choose. If someone
worked late one night, it is counterproductive to demand that they
show up early the next morning, too tired to do any productive work. 
There is a saying that if a developer is at the office at 9:00 in the
morning, it is because he or she worked through the night. 

Developers reach a point where their brains stop working (about once a
month in an intense programming environment). They should be able to
take a day or two off with no loss of pay. Without this time off,
productivity is usually so low as to be almost worthless. 

When a project is completed, all of the developers on the project
should be given an extra week or two off immediately. Developing a
product is like running a marathon: you need to let your brain unwind
when you are done.

Each developer should have his or her own office. At worst, there
should only be two developers in an office (not a partition, but a
real office with walls to the ceiling and a door that can be closed).
Developers need to concentrate for extended periods of time and an
office gives them the privacy and quiet to do so. 

At my previous job, I moved the developers out of one large office
into two-person offices. Within a week, they all told me their
productivity had increased enormously. They were no longer being
constantly interrupted. 

Finally, eliminate the dress code. I have never met an adequate
programmer who wore a tie to work. I have met many very good
programmers who wore shorts and sandals to work. If you require
developers to wear ties, you are telling them that how they look is as
important as what they do. 

Can you imagine a book-publishing company working like a software
company? Imagine telling William Shakespeare that he had to design a
book with a committee of writers. Then he could write some of the
chapters, but others would write the rest of the book. Weekly meetings
would ensure that the chapters flowed together.

Software companies do this daily. When you think