[prog] State of software engineering profession
jennyw
jennyw at dangerousideas.com
Wed Apr 16 10:18:01 EST 2003
On Mon, Apr 14, 2003 at 12:29:10PM -0700, Laurel Fan wrote:
> Have you looked in to Extreme Programming and Agile Methods in
> general? Some of the basic concepts are accepting that requirements
> and priorities will change, and taking advantage of this fact, and
> valuing getting stuff working over bureaucracy such as milestones and
> big design documents.
>
> http://agilemanifesto.org/
> http://www.xprogramming.com/
That's what I was thinking, too! One of the biggest problems with
software engineering is that the customers rarely knows what they really
want. With traditional development, there's a long time between
requirements and coming up with something (even a prototype) that the
customer can look at and review. With iterative development in the XP
sense, something will be running within a week, with features added
every week (or whatever the agreed upon interval is). This way, changes
to requirements can be made on the fly, and because the customer is more
involved, they can more clearly see how their decisions affect
development time.
One of the things that I like about XP is that you're not supposed to
make commits unless everything compiles and all the tests run. Test
first is another great thing -- not only does it guarantee that unit
tests will exist for all parts of the program, but because the tests are
written first the programmers need to think about how methods,
procedures, functions will be used programmatically first. Seems like a
small thing, but I've run into many cases in the past where someone has
written a class or library only to realize that when people use it there
are problems with the interface.
Refactoring is another important aspect. Too often I've heard people say
that a program needs a complete rewrite. Constant refactoring
(improving existing code without changing functionalilty) helps keep a
program in an easy to maintain state.
Of course, XP as a whole probably wouldn't work well for kernel
programming, and almost certainly wouldn't work when inventing something
completely new (where there is no clear customer; or something that
would make a market as opposed to being targeted at an existing one).
But for 80 percent or so of programming (e.g. productivity apps,
vertical market apps, business apps) it works very well.
Even in those cases, projects could probably benefit from short
iterations, frequent refactoring, and unit testing.
Jen
More information about the Programming
mailing list