Traditional Vs. Modern Software Engineering
Rhett Liu
What I want to find out is what is the main difference between
Traditional and Modern SE,or whether Traditional and Modern concepts
commonly exist.
I've sought for the answer some days,but it seems the names commonly
exist,but rare definition could be found.It seems when people talk
Modern SE,they just assume years' ago is Traditional,no definition
given,even it's some blur,but in the "modern" context,I think it should be.
I dill into this just because our SE textbook organize the contents
mainly by dividing them into Traditional and Modern.In the
textbook,structured design and programing is Traditional,object-oriented
is modern.This is what I can't follow.As I know,nowadays a lot of
projects are structrued programmed even huge ones,is it right.
There's another saying in the textbook "structured (requirements &)
analysis",I've not heard before,even it may be right,assuming in
procedure control system,but requirements analysis is also structured
which is just concepts in programing,I'm surprised,I hope for your
explanation if it's right.
Another difference saying is that,Traditional is based on (or imported
from) Building,Modern is evolved to conquer the reality problem in
software,like project management which is critical while the builders
are working with(comsuming) intelligence,and most important,Requirements
change is much more serious in software compareing to building,so
Modern SE comes to nowadays.
Thanks in advance!
Michael Feathers
"Rhett Liu" <rhet...@yahoo.com> wrote in message
news:bku8j0$288r$1...@mail.cn99.com...
> Currently, I am confused by Traditional and Modern Software Engineering.
> What I want to find out is what is the main difference between
> Traditional and Modern SE,or whether Traditional and Modern concepts
> commonly exist.
> I've sought for the answer some days,but it seems the names commonly
> exist,but rare definition could be found.It seems when people talk
> Modern SE,they just assume years' ago is Traditional,no definition
> given,even it's some blur,but in the "modern" context,I think it should
be.
> I dill into this just because our SE textbook organize the contents
> mainly by dividing them into Traditional and Modern.In the
> textbook,structured design and programing is Traditional,object-oriented
> is modern.This is what I can't follow.As I know,nowadays a lot of
> projects are structrued programmed even huge ones,is it right.
Different people use different terms. To me, what is called "traditional"
software development really has more in common with "high modernism", the
idea that you can use a great deal of planning to squeeze all uncertainty
out of a social system and run a group of people like a machine. It's an
old idea and it can work, but it is expensive and it is unnatural in many
ways. We made a lot of progress in the 20th century using modernist ideas
in production, space and aeronautical engineering, etc. But there were
plenty of failures also.. planned economies didn't fare well, for instance.
If you look around, many of the ideas that are ascending in engineering
today are not really modernist. Lean production, for instance, has a
different model of people and problem solving. The same is true in agile
software development.
One thing that is true is that there is this divide between people who are
used to modernist approaches and people who are comfortable with pushing
autonomy downward in process. To the former, often it just looks like
chaos.
Michael Feathers
www.objectmentor.com
JXStern
wrote:
>Currently, I am confused by Traditional and Modern Software Engineering.
>What I want to find out is what is the main difference between
>Traditional and Modern SE,or whether Traditional and Modern concepts
>commonly exist.
>I've sought for the answer some days,but it seems the names commonly
>Modern SE,they just assume years' ago is Traditional,no definition
>given,even it's some blur,but in the "modern" context,I think it should be.
>I dill into this just because our SE textbook organize the contents
>mainly by dividing them into Traditional and Modern.
What is the textbook (and what language is it in?)
Google turns up a lot of hits for "traditional software engineering",
but as you say, there seems no central definition, other than
publication before about 1985.
It might help to remember what things were like *before* this
"traditional" period! People would try to build systems just a piece
here and a piece there, without any real roadmap of process, without
assembling a roadmap of the system first. They often painted
themselves into corners, or missed some critical feature until late in
the game, or otherwise had to backtrack, which was seen as a bad
thing. And if it was a bad thing, do you even realize why? Not
because of the programmer time wasted, but because of the *computer*
time wasted!
Today, computer time is essentially free, and the microeconomics of
software is different. That may be the REAL difference between modern
and traditional!
I would say that the other important factor would be that everyone,
even the most extreme XP wienie, now takes for granted most of the
stuff that the "traditional" publications talk about. Decompose a
problem into components - well, duh! But that was big news, circa
1975.
Joshua Stern
David Lightstone
"JXStern" <JXSternC...@gte.net> wrote in message
news:8g06nvo38rsapp4u7...@4ax.com...
Correct me if I am wrong, but wasn't the THE operating system developed by
Dykstra before 1985
The idea of the layered architecture was present. Whether the managers who
were authorizing system implementation were aware of this I do not know, nor
do I really care.
In the category of painting into corners, some, such as I, might say that
the Agile like methods (well at least those that rely upon the customer
deciding the implementation goals) expose the effort to such problems.
>
> Today, computer time is essentially free, and the microeconomics of
> software is different. That may be the REAL difference between modern
> and traditional!
I agree with your economic analysis
JXStern
<david._NoSp...@prodigy.net> wrote:
>Correct me if I am wrong, but wasn't the THE operating system developed by
>Dykstra before 1985
>The idea of the layered architecture was present. Whether the managers who
>were authorizing system implementation were aware of this I do not know, nor
>do I really care.
Layered stuff goes back at least to the early 1970s, probably the
original Multics documents use it, probably mainframe VM/CMS/TSO uses
it. But that's not quite the same idea, and not quite early enough,
either. I'm thinking of the "pre-traditional" times as basically
pre-IBM 360, pre-Yourdon, pre-"Goto considered harmful."
>In the category of painting into corners, some, such as I, might say that
>the Agile like methods (well at least those that rely upon the customer
>deciding the implementation goals) expose the effort to such problems.
Agile methods work under the new economics. Thus, what I would say
about them is that they ignore such issues -- they are happy to
repaint the corner five times, since it's so cheap to do so. Whether
this constitutes good methodology is still an open question.
>> Today, computer time is essentially free, and the microeconomics of
>> software is different. That may be the REAL difference between modern
>> and traditional!
>
>I agree with your economic analysis
Follow the money.
J.
Rhett Liu
>
>
> What is the textbook (and what language is it in?)
>
It's just a book wrote by one of our institute's teacher,I just feel it
unacceptable to organize the contents by Tradition and Modern,what's
worse is the dividsion standard is whether structured of OOd,so I seek
for the source,the difference between them,and hope for a history view
of the SE.
I haven't study the SE professionly,but I take the difference like this:
the Traditional SE was just the start of the SE,in this stage people
realize the software crisis and go to conquer it.all are start,not much
systmic,not much matrue.
As for modern SE,even it is still not mature,because the crisis is still
there,projects are still bringing developers headache,the industry is
still crying for effiece.But however,it is a new stage,new scape,we have
OO,XP,Agile,Clean Room;we deep into Customer Requirements,System
Design,Implementation,Testing,Maintence.SE now is stepping to much more
systemic,more engineering,from production's initial start to final
market-withdraw.It's no longer just focused and design and coding.
But it's mentioned that 1970s,is it the boundary?I hope for some
reason,and is there any milestone?
JXStern
wrote:
>> What is the textbook (and what language is it in?)
>
>It's just a book wrote by one of our institute's teacher,I just feel it
>unacceptable to organize the contents by Tradition and Modern,what's
>worse is the dividsion standard is whether structured of OOd,so I seek
>for the source,the difference between them,and hope for a history view
>of the SE.
It might be interesting to organize by Traditional/Modern, but more
for an advanced class, not as an introduction to SE.
>I haven't study the SE professionly,but I take the difference like this:
>the Traditional SE was just the start of the SE,in this stage people
>realize the software crisis and go to conquer it.all are start,not much
>systmic,not much matrue.
I can agree with that.
>As for modern SE,even it is still not mature,because the crisis is still
>there,projects are still bringing developers headache,the industry is
>still crying for effiece.But however,it is a new stage,new scape,we have
>OO,XP,Agile,Clean Room;we deep into Customer Requirements,System
>Design,Implementation,Testing,Maintence.SE now is stepping to much more
>systemic,more engineering,from production's initial start to final
>market-withdraw.It's no longer just focused and design and coding.
I also agree that the modern SE is not mature. As I've said, what has
changed is the economics, and that just picks different values out of
the stuff from traditional times, and even pre-traditional.
>But it's mentioned that 1970s,is it the boundary?I hope for some
>reason,and is there any milestone?
Multics clones including Unix started to spread, bringing along the
Algol-like (block structured) C language, and that was the traditional
period.
By the late 1980s, PCs with GUIs became common, cheap, and powerful,
bringing along Smalltalk, C++, and OOP, allowing the first "agile"
methods to be economically feasible, and that is the modern period.
I think we will be stuck with the present situation until there is
another quantum leap in technology, at least equal to the introduction
of OOP.
Joshua Stern
Phlip
> I haven't study the SE professionly,but I take the difference like this:
> the Traditional SE was just the start of the SE,in this stage people
> realize the software crisis and go to conquer it.all are start,not much
> systmic,not much matrue.
I was just recently wondering how to explain how "traditionally" is
traditionally used.
> As for modern SE,even it is still not mature,because the crisis is still
> there,projects are still bringing developers headache,the industry is
> still crying for effiece.But however,it is a new stage,new scape,we have
> OO,XP,Agile,Clean Room;we deep into Customer Requirements,System
> Design,Implementation,Testing,Maintence.SE now is stepping to much more
> systemic,more engineering,from production's initial start to final
> market-withdraw.It's no longer just focused and design and coding.
>
> But it's mentioned that 1970s,is it the boundary?I hope for some
> reason,and is there any milestone?
Consider this usage:
'Traditionally, the most common "organic design" lacks tests and aggressive
refactoring. It leads to long, run-on functions. If we had refactored
nothing, and only added tests and code, by now our function
putSvgIntoCanvas() would be very long, and new abilities would be hard to
add.'
The meaning of "Traditionally" varies directly with context. As a literary
artifice, it can only mean "I am now going to describe the way to do it that
opposes my ensuing narration".
In this exact context, the opposite of "organic design" may mean different
things to different organisms. Before highly incremental processes,
programmers would spend allotted periods of time designing (the feared and
hated "Waterfall"), and their designs would not "grow". They would appear
fully formed. Contrarily, other programmers allotted no time or resources to
design (the feared and hated "Code-n-Fix"), and their designs would grow all
over the place.
The cited paragraph can only mean that organic growth is good. But to
illustrate this, it must pretend there was another tradition to compare to.
This artifice enables the paragraph merely to state the same thing twice,
once in the negative and again in the positive.
So the word can only carry the implication that known wrong ways to do it
came before right ways. There may still be new wrong ways to be discovered!
--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
Michael Feathers
"Phlip" <phli...@yahoo.com> wrote in message
news:NhQcb.7860$FN6...@newssvr32.news.prodigy.com...
> Rhett Liu wrote:
>
> > I haven't study the SE professionly,but I take the difference like this:
> > the Traditional SE was just the start of the SE,in this stage people
> > realize the software crisis and go to conquer it.all are start,not much
> > systmic,not much matrue.
>
> I was just recently wondering how to explain how "traditionally" is
> traditionally used.
The traditional/modern boundary seems right, but it seems that the books
haven't caught up with post-modern software development yet.
http://www.mcs.vuw.ac.nz/comp/Publications/CS-TR-02-9.abs.html
:-)
Andrew Gabb
does post-modernism for that matter:=) Software development
techniques have been changing rapidly since they started 50 years or
so ago (ignoring Ada Lovelace of course - she was a theorist not an
engineer).
Your lecturer probably means structured analysis and design (SA&D)
for 'traditional' and OOA&D for 'modern' but this is a very
simplistic view of the world.
Andrew
--
Andrew Gabb
email: ag...@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021, fax: +61 8 8269-3280
-----
Rhett Liu
> 'Traditional' doesn't make much sense in software engineering (nor does
> post-modernism for that matter:=)
I agree with you,they are just used to convenient something or just as
amazing titles for books,and it should be used in some were consider the
SE today is really an new scape,so I think I've got the answer,SE is
still stepping forward,maybe in the day it achieved the originally
indurstry and developer's goal,there will be an more appropriate history
review.