Software Engineering: An Idea Whose Time Has Come and Gone?
16 views
Skip to first unread message
Ronaldo Ferraz
Jul 19, 2009, 12:59:04 PM7/19/09
to programm...@googlegroups.com
http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
Não li ainda, mas é do Tom DeMarco e casa bem com a idéia da lista.
Abraços,
R.
Ronaldo Ferraz
Jul 20, 2009, 6:24:29 PM7/20/09
to programm...@googlegroups.com
Complementando com outro artigo para leitura assim que der tempo. :)
http://www.ddj.com/architect/217701907
Abraços,
R.
2009/7/19 Ronaldo Ferraz <ronald...@gmail.com>:
Thiago Silva
Jul 24, 2009, 3:44:24 PM7/24/09
to programm...@googlegroups.com
Reuni os textos abaixo para uma discussão uns meses atrás, acho que
vem a calhar nesta thread (talvez com algumas curvas). Autores
incluem: Alan Kay, Andries Van Dam e Terence Parr.
* Is "Software Engineering" an Oxymoron? [1]
Real Software Engineering is still in the future. There is nothing in
current SE that is like the construction of the Empire State building
in less than a year by less than 3000 people: they used powerful ideas
and power tools that we don’t yet have in software development. If
software does “engineering” at all, it is too often at the same level
as the ancient Egyptians before the invention of the arch (literally
before the making of arches: architecture), who made large structures
with hundreds of thousands of slaves toiling for decades to pile stone
upon stone: they used weak ideas and weak tools, pretty much like most
software development today.
The real question is whether there exists a practice in between the
two - stronger than just piling up messes - that can eventually lead
us to real modern engineering processes for software. [...]
One of the ways to characterize the current dilemma is that every
project we do, even those with seemingly similar goals has a much
larger learning curve than it should. This is partly because we don’t
yet know what we really need to know about software. But as Butler
Lampson has pointed out, this is also partly because Moore’s Law gives
us a qualitatively different environment with new and larger
requirements every few years, so that projects with similar goals are
quite different. [...]
In short, you can make something as simple as a clock and fix it when
it breaks. But large systems have to be negotiated with, both when
they are grown, and when they are changed. This is more biological in
nature, and large systems act more like ecologies than like simple
gear meshing mechanisms.
* Software: Art, Engineering, Mathematics, or Science? [2]
We need to do more building of important software structures, and we
need to do it in a form that allows analysis, learning, and
reformulating the design and fabrication from what has just been
learned.
There seems to be a bit of a chicken and egg problem here. If we don't
really have an engineering discipline, then won't it be too difficult
to make big constructions that are also understandable enough to learn
from? And won't the mess we've made be too difficult to reformulate to
give us a chance to understand whether our new findings really have
value?
* A Conversation with Alan Kay [3]
If you look at software today, through the lens of the history of
engineering, it's certainly engineering of a sort--but it's the kind
of engineering that people without the concept of the arch did. Most
software today is very much like an Egyptian pyramid with millions of
bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.
* Worse then merely reinventing the wheel [4]
Alan Kay: [...] For example, not thinking through programming enough
-- and especially not thinking through the design of a programming
language enough -- can produce a complete rat's nest of more
complexity, where what was needed was a much better approach to
architectures that can better handle various kinds of scaling. Or,
making a partial solution to visualizing data structures on the web,
but not handling the kinds of authoring and environments needed --
i.e. the web browser -- can lead to the most horrible situations and
gunked up media, especially for the end-users. Both of these examples
could be termed "reinventing the flat tire", which is a much worse sin
than merely reinventing the wheel.
[...] Tiny limited-perspective views which make a bigger mess in a
environment are not just found in computing, but in many areas in
which people are working from confined goals that have little systems
sense. However, to have computing be one of the worst offenders -- the
field that created some of the best systems ever invented: Ethernet,
Internet, etc. -- seems both wrong and even embarrassing.
* Why writing software is not like engineering [5]
Writing software is more an art than an engineering discipline.
Writing software is most similar to writing fiction novels. Writing
novels is also an act of creation in an unconstrained and ethereal
medium with few well-established construction rules. We know good
writing when we see it, but it is hard to teach. Experience writing
and feedback from better writers (coders) is the most reliable means
of becoming a good writer (coder). Without a well understood process,
software will remain more an art than a science. The term "software
engineering" is more a goal than how we actually write software.
* Program for the future [6]
Andries: If we are not trainning our engineers to use the powerful
tools of our trade, there must be something wrong with the way we
educate them.
* Alguém na internet [?]
For most of us, software engineering means "hacking together a solution"
[1] - http://www.cin.ufpe.br/~tbls/IsSoftwareEngineeringAnOxymoron.pdf
[2] - http://guzdial.cc.gatech.edu/squeakbook/AlansForeword.html
[3] http://portal.acm.org/ft_gateway.cfm?id=1039523&type=pdf
ou http://queue.acm.org/detail.cfm?id=1039523
[4] - Prediction and Invention: Object-oriented vs. functional
http://www.amazon.com/gp/blog/post/PLNKVUNBWIDAS9YQ
[5] http://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html
[6] https://admin.adobe.acrobat.com/_a295153/p99875217/
2009/7/20 Ronaldo Ferraz <ronald...@gmail.com>:
--
Thiago Silva
Computer Science
M.Sc. Candidate at Federal University of Pernambuco
jabber/gtalk: tsi...@jabber-br.org
http://blog.sourcecraft.info
vem a calhar nesta thread (talvez com algumas curvas). Autores
incluem: Alan Kay, Andries Van Dam e Terence Parr.
* Is "Software Engineering" an Oxymoron? [1]
Real Software Engineering is still in the future. There is nothing in
current SE that is like the construction of the Empire State building
in less than a year by less than 3000 people: they used powerful ideas
and power tools that we don’t yet have in software development. If
software does “engineering” at all, it is too often at the same level
as the ancient Egyptians before the invention of the arch (literally
before the making of arches: architecture), who made large structures
with hundreds of thousands of slaves toiling for decades to pile stone
upon stone: they used weak ideas and weak tools, pretty much like most
software development today.
The real question is whether there exists a practice in between the
two - stronger than just piling up messes - that can eventually lead
us to real modern engineering processes for software. [...]
One of the ways to characterize the current dilemma is that every
project we do, even those with seemingly similar goals has a much
larger learning curve than it should. This is partly because we don’t
yet know what we really need to know about software. But as Butler
Lampson has pointed out, this is also partly because Moore’s Law gives
us a qualitatively different environment with new and larger
requirements every few years, so that projects with similar goals are
quite different. [...]
In short, you can make something as simple as a clock and fix it when
it breaks. But large systems have to be negotiated with, both when
they are grown, and when they are changed. This is more biological in
nature, and large systems act more like ecologies than like simple
gear meshing mechanisms.
* Software: Art, Engineering, Mathematics, or Science? [2]
We need to do more building of important software structures, and we
need to do it in a form that allows analysis, learning, and
reformulating the design and fabrication from what has just been
learned.
There seems to be a bit of a chicken and egg problem here. If we don't
really have an engineering discipline, then won't it be too difficult
to make big constructions that are also understandable enough to learn
from? And won't the mess we've made be too difficult to reformulate to
give us a chance to understand whether our new findings really have
value?
* A Conversation with Alan Kay [3]
If you look at software today, through the lens of the history of
engineering, it's certainly engineering of a sort--but it's the kind
of engineering that people without the concept of the arch did. Most
software today is very much like an Egyptian pyramid with millions of
bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.
* Worse then merely reinventing the wheel [4]
Alan Kay: [...] For example, not thinking through programming enough
-- and especially not thinking through the design of a programming
language enough -- can produce a complete rat's nest of more
complexity, where what was needed was a much better approach to
architectures that can better handle various kinds of scaling. Or,
making a partial solution to visualizing data structures on the web,
but not handling the kinds of authoring and environments needed --
i.e. the web browser -- can lead to the most horrible situations and
gunked up media, especially for the end-users. Both of these examples
could be termed "reinventing the flat tire", which is a much worse sin
than merely reinventing the wheel.
[...] Tiny limited-perspective views which make a bigger mess in a
environment are not just found in computing, but in many areas in
which people are working from confined goals that have little systems
sense. However, to have computing be one of the worst offenders -- the
field that created some of the best systems ever invented: Ethernet,
Internet, etc. -- seems both wrong and even embarrassing.
* Why writing software is not like engineering [5]
Writing software is more an art than an engineering discipline.
Writing software is most similar to writing fiction novels. Writing
novels is also an act of creation in an unconstrained and ethereal
medium with few well-established construction rules. We know good
writing when we see it, but it is hard to teach. Experience writing
and feedback from better writers (coders) is the most reliable means
of becoming a good writer (coder). Without a well understood process,
software will remain more an art than a science. The term "software
engineering" is more a goal than how we actually write software.
* Program for the future [6]
Andries: If we are not trainning our engineers to use the powerful
tools of our trade, there must be something wrong with the way we
educate them.
* Alguém na internet [?]
For most of us, software engineering means "hacking together a solution"
[1] - http://www.cin.ufpe.br/~tbls/IsSoftwareEngineeringAnOxymoron.pdf
[2] - http://guzdial.cc.gatech.edu/squeakbook/AlansForeword.html
[3] http://portal.acm.org/ft_gateway.cfm?id=1039523&type=pdf
ou http://queue.acm.org/detail.cfm?id=1039523
[4] - Prediction and Invention: Object-oriented vs. functional
http://www.amazon.com/gp/blog/post/PLNKVUNBWIDAS9YQ
[5] http://www.cs.usfca.edu/~parrt/doc/software-not-engineering.html
[6] https://admin.adobe.acrobat.com/_a295153/p99875217/
2009/7/20 Ronaldo Ferraz <ronald...@gmail.com>:
Thiago Silva
Computer Science
M.Sc. Candidate at Federal University of Pernambuco
jabber/gtalk: tsi...@jabber-br.org
http://blog.sourcecraft.info
Reply all
Reply to author
Forward
0 new messages