piclist 2009\01\31\175030a >
Thread: Positive experiences with software development
face BY : Vitaliy email (remove spam text)

Gerhard Fiedler
{Quote hidden}

I no longer believe in the magic of documentation, after we spent close to
six man-months and ended up with nothing but a pile of paper.

There is no such thing as perfect communication. It's not my idea, but I
fully subscribe to it. The knowledge is stored in the members of the
development team, it's the so-called "project story". When all the
developers leave, the story is lost, no matter how much documentation they
leave behind. The new team has to develop its own project story. They may
use the documentation the old team left behind, but the story will be their

The implication is that you shouldn't fixate on documentation, but instead
find efficient ways to communicate the ideas.

> There's also the situation where you need to have enough documentation
> to be able to show that a failure was not your problem, that it
> originated somewhere else. This can be quite important, both in terms of
> client relationships and commercially.

I don't doubt your statement is true in many situations, but it is sad
nonetheless. Instead of delivering working software, programmers are forced
to cover their behinds with lots of useless paper.

>> - Sketching out the design on a whiteboard.
> Is often helpful. I like drawings, and I don't have a problem of being
> shown wrong in front of a group. But in my experience it's a minority of
> team members that take active roles in such sketching meetings. It's not
> everybody's thing to speak out ad-hoc thoughts in front of a group. If
> you want to leverage the ideas and experience of these people, you need
> to provide a different setting for them.

Hm, I don't know about that. Active participation can be defined as
listening and watching other team members discuss the design. The beauty of
the whiteboard is that everybody sees the same thing at the same time, and
it's easy to point at what's been written/drawn.

>> - Refactoring is the way to keep code maintainable, and is usually
>> what I resort to when I dig myself into a hole
> Agreed. However, also here is a balance. There is code that is difficult
> to refactor, and a refactoring that takes a week, say, may take a month
> or two of lots of testing and occasional debugging to get to the
> stability the code had before. Now it's better, because better
> structured, but what I'm saying is that refactoring is not always as
> inexpensive as it looks.

I would argue that refactoring has a net benefit, because the cost of *not*
refactoring is usually high. If a customer reports a bug, and the code is
such a mess that you can't find it, you lose future business. If the
customer asks you to implement a new feature, and you tell them you can't
because it'll break your existing spaghetti code, you lose money again.

It's not black and white either: early refactoring is less expensive than
late refactoring.

>> - Object Oriented design, which is even possible in C
> I don't buy that this is important for success of programming projects
> in general. It's possible, but I think whether it's helpful depends a
> lot on the specific problem.

The fundamental difference b/w procedural programming and OOP, is that OOP
creates an additional layer of abstraction, and helps manage complexity. For
projects with a  low level of complexity, it may not be necessary.

>> I would love to hear what tools/techniques/practices other people find
>> useful in their work.
> I tried to convey this in my previous messages... Be flexible, look at
> every aspect of the situation, get to know the people involved (this
> includes you!) and their strengths and weaknesses, how they work and
> what they need, like and dislike, and /adapt/. No matter whether a
> technique is "Agile" or not... if it works in a given situation, it's
> the way to go.

That's the whole point, isn't it -- figuring out what works in a given
situation. You can't possibly try everything, so you need to make educated
guesses what is likely to produce the best outcome. That's what I was asking
about, but you guys don't seem to want to share your hard-won knowledge...


<22E7F9AC3E504E808B53E57D217C6303@ws11> 7bit

See also: www.piclist.com/techref/index.htm?key=positive+experiences
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Positive experiences with software development

month overview.

new search...