Positive experiences with software development
Gerhard Fiedler email (remove spam text)
Until you find yourself in a situation where something that didn't work
> I've been a part of two failed projects. One project failed because we
> drowned it in documentation.
I've seen that, too. But I've also seen projects go well because of
extensive documentation -- and I've seen projects not go well because of
lack of sufficient documentation.
I've seen it quite often that my initial progress is slow. I tend to dig
myself into the problem, digest it for a while, and this may take weeks
without a single line of code. But when I start on it, there are only
very few surprises, and possibly none that requires a change of
It's always a matter of the right measure.
> The other one died mainly because we tried to reinvent too many
> wheels, instead of using existing frameworks and components.
This also happens, just as its counterpart: spending too much time with
existing and known frameworks, just to find out at the end that the work
to coerce them to do what you need to do is much more than a proprietary
solution would have been. Tends to happen when sufficient pre-planning
See, this is one nice example. In order to decide whether the (sometimes
substantial) effort to start using a certain framework is worth it, you
need to plan pretty far ahead and know the final requirements rather
well, or else you may find yourself with a lot of investment in a
framework that just doesn't get you where you need to go.
> Projects that succeeded, in general had the following characteristics:
> - We jumped to implementation early in the project: to prove a concept,
> build a quick mockup or a prototype
Is good for some projects, not so good for others. There's the approach
that just doing it gets you somewhere quickly. There's also the approach
that an hour thinking and planning ahead can save you many hours later.
This is not an either-or situation, this is about the right measure and
applying the right approach to the right problem.
The projects I've seen failing usually failed because of a lack of
planning, mostly estimating. There are situations where it doesn't help
the project if you successfully create ten iterations that all do a
subset of what's finally required if you can't get to the full
requirements within budget. In those cases, the effort spent for the ten
iterations is simply wasted, because of a lack of planning. If the
minimum required is too much to do within the budget, don't even start
-- but this requires planning ahead.
> - There was lots of communication between developers
This is always good. The ten thousand dollar question is how to get your
team to efficiently communicate. Which depends a lot on the team and
many other constraints of the situation.
> - Only the bare minimum of documentation was created, most of it of
> the "sketch on a napkin" type.
Of course. To do it right, you always do the minimum required (in
engineering, at least). Everything beyond the required minimum is
ballast. But the problem is that the minimum required varies
considerably with the type of project. There are programs where what
they do, in principle, can be conveyed in a fifteen minute conversation.
There are others that are so complex that you need a few people working
on it for a year to gather what the program should do. If they don't
document what they did during that time, it's lost, and if they do, it's
a huge amount of documentation. And before they do this, nobody has a
clue about the scope of the work, so it's not possible to even talk
about a reasonable contract.
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.
> - Many iterations, based on the changing requirements
As I said above, this is a good thing in some situations, but it doesn't
guarantee the success. And again it's a question of the right measure.
> - Version control, which acts as a safety net, and encourages
Right... now every software team effort that doesn't use version control
should better get a different manager or lead :) I thought this was
understood to be a basic thing.
> - Weekly meetings with involved parties
Nice to have, but geographical constraints may make this inefficient.
> - 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.
> - 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.
> - 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.
> - Writing code in the most straightforward way, even at the expense of
> performance/code size when necessary
Agreed. (FWIW, I think that whether OO is or is not the most
straightforward way depends a lot... on many factors.)
> 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. There is a place for pre-defined requirements, ad-hoc
coding, Gantt charts, early prototypes, months of planning, programming
in couples, groups, and alone in your home, writing heaps of good
documentation, quick iterations... it really depends on the specific
situation. Don't be afraid to use a technique just because Turble
Bigshot wrote that it can't work :)
In reply to: <B3AC5EFEB126499BB2CED6CA3070E8E5@ws11>
See also: www.piclist.com/techref/index.htm?key=positive+experiences
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the