[Ilugc] software development practices
- From: lawgon@xxxxxxxxxxxxxxx (kenneth gonsalves)
- Date: Fri, 01 Jun 2012 16:49:05 +0530
On Tue, 2012-05-29 at 21:41 +0530, Balachandran Sivakumar wrote:
Hi Kenneth,
On Tue, May 29, 2012 at 6:32 PM, kenneth gonsalves
<lawgon at thenilgiris.com> wrote:
has anyone have any idea as to what is meant by 'software development
practices' and whether this term is applicable to open source software
development?
Software development practices are applicable to any
software - irrespective of open source or not. The term, simply put,
means an organised and scientific way of creating software. To state a
few examples: use of a version control system, collecting and
documenting the requirements for which we are developing the software,
etc.
In the open source world, development practices include having a
writing well-commented code, dev wiki, dev mailing list, a public bug
tracker, (at least) a basic How To for the users, a proper build
system, etc. Thanks
(caveat: this post is based mainly on personal experience and put here
to see how others in both the open source field and the proprietary
field feel about this)
thanks to all who responded. I now understand that the term is supposed
to mean the development cycle for a software project. This, in my
opinion, is radically different for foss and prop software. I have had
only 3 experiences in developing prop, and all ended up in my being
booted out fairly early in the process, so I am not sure if my
observations are accurate. The cycle as I see it is like this:
1. Sales meets the clients and promises them anything under the sun, fix
a price and get an agreement and an advance. After that sales is out of
the picture.
2. Design then meets the clients and draw up an elaborate set of specs
and get the client's approval. After that, design is out of the picture.
3. The design is then sent to production. The job is parceled out to
several teams, each team working in isolation from the other teams. I
will not go into how these teams operate, but the general atmosphere is
- if it works, it is fine and peer review and criticism of another's
code is seen as a deadly insult. Obviously a lot of the code is
duplicated as no team knows what the other teams are doing, and, no one
will anyway admit that another person's solution is better than his.
Note that the teams do not have any contact with the clients. When the
teams finish their assignments, most of the members move on to other
projects leaving a skeleton team to cope with the next stage.
4. Now the integration team moves in. They are the elite and highly paid
and their job is to somehow get everything to work together. They do a
lot of reverse engineering and 'adjustments' and finally pronounce
themselves satisfied.
5. Then testing takes over - all tests are with simulated data and with
the help of the integrators the tests are pronounced done.
6. The product is then dumped on the hapless client and he is left to
the tender mercies of support. In the period of development, a lot of
his needs have changed and he needs many things he has not contracted
for. Also with real data, many bugs appear. Some clients decide to live
with it - others go to another vendor, and the same process starts
again. The client very often spends more to get the whole thing working
in some fashion or the other than on the original application.
note that the tools used are irrelevant to the process. Of course people
will say that these practices are only followed by lowlifes, and good
software developers use a lot of open source tools and methods and are
very scientific in their approach. So let us look at IBM. Produces great
software, is ethical and a very sound supporter of open source. Some
years back a wildly hilarious discussion went on in the django
developers mailing list. The thread is here:
http://groups.google.com/group/django-developers/browse_thread/thread/80f73f8bbf93c039/d598b3d4d67301a8?#d598b3d4d67301a8
To summarise the thread, IBM wanted to release Django drivers for their
databases, so they asked the Django developers for the 'specs'. The
reply: download django, make a copy of an existing driver, tweak it for
your database, make sure it passes all the tests and you have a driver.
IBM was horrified - we cannot download or even look at your code as our
engineers will get tainted and we can no longer use them - so give us
specs. The django team was not willing to waste their time on this.
Eventually IBM released the drivers. I suppose they got some engineer to
look at the code, write the specs and then they must have terminated him
with extreme prejudice ;-) When pharaoh died, he was buried with all his
wealth. The tomb was cleverly constructed with a lot of booby traps to
prevent looters from getting in. Often the location was secret. And the
architects, builders and slaves who built the tomb were killed and
buried with him - all in the name of secrecy and security. Prop software
has two constraints - one cannot reuse code (even code written by the
concern for another client) and one cannot let all and sundry see the
whole of the code base - so these 'developers' do not know whether they
are dealing with an elephant or a donkey. (it is usually a donkey)
I have also had some experience where the client has agreed that the
application be developed as open source. Since secrecy is no longer an
issue, The same team does everything from sales to support, and the
client and his employees are also members of the team. The process is
something like this:
1. Meet the client and convince him to take your app and also have it
developed as open source. Take advance and make the agreement. Make sure
that the person who actually takes the decisions is on board, otherwise
you are wasting your time.
2. Identify a key area to work on and set up a *loose* set of specs -
this is going to change anyway. It is crucial that this key area is
relatively fast to set up as this will be used to get the client's
people up to speed on the open source way of doing things.
3. Discuss everything on a mailing list where all stakeholders can
participate.
4. Write the module - note that anyone writing any of the code has to
also write the tests and make sure the code passes the tests and also
works with the existing code base. This eliminates the testing phase and
there is no need for an integrator. Also the code should be well
commented and documented, which eliminates the need to get people to
write manuals.
5. Install the module for the client and ask them to start feeding real
data and to start using the module in production as soon as possible.
6. Insist that all problems be reported as issues in the bug tracker and
train the client how to do this - it is not rocket science. Make sure
all issues are dealt with as soon as possible. At least the issues
should be accepted/rejected immediately and frequently updated until
resolution. This is the most important point - training the client to be
a co-developer.
7. Do not focus on look and feel at this stage, but be very flexible on
making changes and doing things that were not initially contracted for.
The client may think he knows what he wants, but usually a lot of this
is based on his experience with doing things manually - computers do not
do things the way people do. Once the client realises this, he is
hooked. Once the initial module is in production, and the team is
comfortable working together, the rest of the work can be done in the
same manner.
8. Writing code: first check your own code base and then the web for
suitable code - make sure it is legal to use it, and then copy, paste
and tweak. Roll your own only if nothing suitable is available. For code
from your own app, the tweaks may be applicable to the original too -
and that is an improvement. Everything should be documented on the
mailing list/bug tracker/wiki, both before and after writing the code.
Of course various members of the team will have specific
responsibilities, but anyone is free to work on any part of the code
(make sure people who cannot be trusted not to mess up everything are
not given commit rights on the main repo - they should fork and make
changes there which can be pulled when checked out by a person with
commit rights.
8. The team will have a structure, but usually no real hierarchy. Of
course you need a person to take final and binding decisions in matters
where there is no consensus. Get rid of anyone who is unable to stomach
criticism of his code - however brilliant he may be. And remember that
ui/ux cannot be done by a committee - entrust this to one person and
leave the decisions to him.
9. When in production, backward compatibility is good, but not an
inflexible rule. When it is broken make sure that all migration scripts
are committed at the same time as the change.
10. At some stage, you may require a users mailing list and to
coordinate all the documentation into a manual - this manual should
practically write itself.
11. If you are lucky, some geeks will appear on the client's side who
start contributing to the project - and if you are really lucky,
outsiders who find the app useful may also start participating.
There is a lot more to be said, but basically this is what I feel is the
difference between open and prop - feedback on other's experiences and
flames are most welcome.
--
regards
Kenneth Gonsalves
Other related posts: