Design Question - Do Your Programs Grow Organically or All Planned?

[jm]

or both? What is the "real world" like with respect to building
programs. Do you start out with a minimal idea, a skeleton and start
working? Do you have everything written out first and then just
translate that model to an application, using a progamming language?
Both? When do you know it is overkill?

Do you sit around, draw something on a table napkin, and then off you
go (a little silly, but could be true)? I would think some of it would
have to do with how large the project is, how many developers are
involved, and so on. I also guess that while the application overview
may be planned, the actually programming may be organic. By that last
one I simply mean that a developer may not really know how to design
functionality x, so they develop something and then use trial and
error.

I would be interested in any links someone may have that shows what a
real lifetime development cycle entails, if anyone has any
recommendations.

Thank you.

 

[Rich]

Ideally, all the requirements are clearly defined before the code is
written. This can be very elaborate with requirement standards
defining how requirements are written and processes set up to
write/review/approve all the requirements (like DO-178B). Done right,
this is a lengthy and tedious process but it results in better code
with fewer bugs. There are software tools for requirement definition
and tracing requirements to tests, etc. In some environments these
processes are required, like it or not (for example in safety-critical
applications like avionics). Do a Google search for "DO-178B" if you
want to see more about this.

In reality most people do at least some "prototype coding" before fully
defining the requirements - in many cases this is basically writing the
code first then writing the requirements to fit. This at least makes
it look like you defined some requirements.

Of course, some people just write the code and go with it without ever
doing anything formal like a requirement document. This is alot faster
but is likely to result in sloppy code full of bugs. You may spend
more time overall because you will go through more debugging and
re-releasing of the code.

 

[clintonG]

You should do some reading about Agile Development. Agile is about as real
world as it gets.

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
MAP http://wikimapia.org/#y=43038073&x=-88043838&z=17&l=0&m=h

 

[Kevin Spencer]

Agreed. Agile combines the best of all worlds. It is efficient, flexible,
and able to handle the vagaries of the software design/development process.
See

http://www.agilealliance.com/

--
HTH,

Kevin Spencer
Microsoft MVP
Ministry of Software Development
http://unclechutney.blogspot.com

Any experience you can walk away from
is a good one.

 

[clintonG]

Yup. Agile development is a series of procedural processes that were adopted
from those that evolved from the design-build process that eventually
replaced design-bid in the AEC markets (Architecture, Engineering,
Construction). At this point in time, agility is the most honest and
realistic expression of the way the real world really works whether we are
building software or school buildings.

There was a period in architectural history where the expression of needless
ornamentation on a building became questionable. Persons such as the Nazi
architect Mies Van der Rohe and the era of modernism brought this about.
Comparitively speaking, Agility foregoes the needless ornamentation of the
software development process. Again, comparitively speaking, software
development is undergoing its own period of modernism but be advised, it is
post-modernism that comes next!

Clear as mud? Read, Read, Read...

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
MAP http://wikimapia.org/#y=43038073&x=-88043838&z=17&l=0&m=h