Software life cycle in Erlang

Ryan Rawson ryanobjc@REDACTED
Wed Jan 25 20:54:18 CET 2006

The best explanation of software "engineering" I have heard is
seperation of "design engineering" and "production engineering". 
Essentially the speaker was arguing that most development would fall
under the umbrella of design engineering - figuring out how to build
it by building it (very common in the engineering world).   Then
derive requirements and specifications from your prototype and
implement it "production-quality".

The places I've worked, we are doing mostly design engineering , and
the results are not just prototypes - they end up in production.  It's
the nature of the fast paced business.

I would therefore posit, that design engineering has and can replace
production engineering.  The major difference is that production
engineering has more error checking (according to this presentation),
and with a language like erlang where you don't write error checking,
it seems the distinction between design and production is blurring.

Personally in my work, I have found scrum useful for team coordination
and communications, and "build something that works quickly" a good
guiding principle.  This only really applies to smaller things that
can be implemented by a small team though.


On 1/25/06, Thomas Lindgren <thomasl_erlang@REDACTED> wrote:
> --- "Eduardo Figoli (INS)" <eduardo@REDACTED>
> wrote:
> > I'm trying to figure out the best model for software
> > development in Erlang.
> The best _model_ seems to be iterative development of
> some sort, perhaps test driven. AXD 301 had great
> success with steadily improving "increments", to take
> one of the great success stories.
> Taking a number like 35% for implementation means your
> whole project is done about 50% faster (in 2/3 the
> time) even if the language permits infinitely faster
> development than the state of the art, simply because
> the rest of the phases aren't concerned with
> programming. (That's the usual argument against
> switching programming languages, of course.) This
> doesn't seem right -- the added flexibility also means
> you can use powerful new development processes.
> My recommendation: try to "switch to better rules".
> Best,
> Thomas
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around

More information about the erlang-questions mailing list