Software Engineering Theory and Methods initiative
Adewale Oshineye
http://blog.oshineye.com/2010/02/new-frontiers-tdd-and-refactoring.html
which aimed to bring together industry and academia to look at the
state of the art in refactoring and TDD. It was productive and
educational for all those who attended. It made me very hopeful about
the future of our craft and our ability to keep on improving our tools
and techniques.
Coincidentally I've recently come across this: http://www.semat.org
It is... fascinating in so many ways.
They start out with sensible premises (software engineering[1] needs
to change, the changes should be based on evidence and data, we should
identify a kernel of stuff we know works) and then:
http://sematblog.wordpress.com/2009/12/19/the-semat-charter-a-proposal/
which says they'll have a Vision Statement in March. They then plan to
spend 12 months reflecting upon that vision statement. At the end of
all of this they'll have more pieces of paper. Maybe even a manifesto.
But very little that's useful to somebody who just wants to get better
at their job.
This is their Call To Action: http://www.ddj.com/architect/222001342
This is their blog: http://sematblog.wordpress.com/
This is their FAQ: http://www.semat.org/bin/view/Main/QuestionsAndAnswers
If I didn't have so much respect for their signatories I would suspect
that this is a parody. You'll note that they have a church so broad as
to be meaningless. I find the idea of Watts Humphrey and Alistair
Cockburn coming to a consensus about software development to be
unlikely.
This blog post:
http://catenary.wordpress.com/2009/11/29/against-semat/ does a good
job of discussing some of the problems behind the SEMAT idea.
I will, of course, be subscribing to their blog. Even though this
looks like a group of people with big egos who will spend several
years talking past each other we might still learn useful lessons from
their counter-example. Looking at their actions from the outside, for
instance this provocative post to the agile-usability list:
http://tech.groups.yahoo.com/group/agile-usability/message/6751 , I
find an uncomfortable similarity to our own actions.
The main difference is that we're rooted in real-world practice and
we're building stuff. As long as the Software Craftsmanship movement
is a productive community that builds software and shares knowledge in
ways that help people improve their skills then we don't have to worry
too much about ending up like them.
[1] Their first mistake is assuming that what we do is a kind of
engineering. I don't see any evidence that they've studied the history
of engineering and decided that there is a strong correlation between
that model and the work we do today. Since they're fundamentally
mistaken about the work we do they seem doomed to thrash around
unproductively.
Michael Feathers
Thanks for that. This is an area I've been interested in for a while.
In fact, I was just visiting James Noble at the University of
Wellington last week and he gave me a number of pointers to current
work on refactoring. As he did, I struck me afresh just how
disconnected academia and practice are. I've recently decided to do
what I can to help bridge the gap, even if its just pointing
practitioners to research I've read about or suggesting practical
areas of research to people in academia.
James, in particular, is someone I've long respected in this area.
One of the most interesting things I've seen in a while was the 'Shape
of Java' project that he was involved in. The idea was to gather
metrics over a very large corpus of Java projects (some open sourced,
some closed) to get a sense of what design is like in the field,
rather than what we usually talk about, which is what we -wish- it was
like in the field.
Happy to know that others are pursuing this,
Michael
> --
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To post to this group, send email to software_cr...@googlegroups.com.
> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
JAndrews
as I've thought about it more, I've decided there are some principles
of good software design and implementation they can probably agree
upon and illuminate.
For context: I spent 15 years as a practicing nuclear engineer before
becoming a practicing software developer.
"Engineering practice", as I found it in the field, is often as
arbitrary as "software development practice". What is "good" is
measured first by "what works", second by "what's elegant", and
finally by "what's inexpensive", and is judged primarily by senior
practitioners working against their own experience rather than some
set of objective standards (though those exist as well). In hardware
engineering, the time lapse between design review and implementation
is quite often very long (especially large-scale design, e.g. power
plants, where I worked). As a result, feedback loops are even longer
and harder to manage. What dominates in the large scale seems to be
"what worked"--and just as often, "what failed".
This seems to me to be exactly the type of thing we're developing now
as developers--we now have lots of categories of languages for solving
different types of problems and we're developing solid tools and
techniques for measuring performance, managing projects, and closing
the loop between design and implementation. The world for software
developers is a FAR less arbitrary place, and has far more development
of tools and techniques, than in 1976 when I started coding.
The body of common practice is regularly changing in hardware
engineering, as analysis tools get better. When I graduated, one of
my first tasks required a stress analysis, which I did with a
calculator by hand. These days, an engineer would set that up in a
desktop finite-element analysis program with a nice UI, and he'd get a
better answer in less time. The principles are the same, though:
determine, through an understanding of material behavior and machine
design, what a specific application required of the machine and what
combination of off-the-shelf components and custom machining could be
used to implement that application. It's very much what I do today: I
pick off-the-shelf components and custom components to create a design
to meet certain requirements.
Can we, as a group, specify some of the principles on which those
decisions get made? I suspect we can. While I'm only really fluent
in one sub-part of OO design, I know of a few; consider the SOLID
principles in OO design, various common design patterns, and the
corpus of tools and techniques in Knuth's "The Art of Computer
Programming".
Arnaud Bailly
Forgetting about the research on "software engineering" that yielded
such beasts as COCOMO or CMMi, there is a at least one huge "academic"
body of knowledge that may have and is known to have had some serious
and concrete practical applications in the field, that I am aware (and
fond) of: Functional programming and programming languages theory. Yet
I believe we are only seeing the "awakening" of this sleeping giant
which has kept chained by imperative programming zealots for years.
Some evidences I would like to provide to this discussion:
- emergence of a whole zoo of FP or FP related languages on VM
platforms: F#, Scala, Clojure, Ioke and non VM
(http://www.mlstate.com)
- introduction of closures and FP constructs (maps, folds and other
higher order functions) in each and every major language, include Jave
itself (after much pain)
- breakthroughs in major practical applications (eg. twitter and
scala, erlang and rabbitmq)
FPs has been extensively studied since at least the 30s and the
invention of the lambda-calculus, has become reality with the
unsurpassed invention of LISP in the 60s (or maybe even the late 50s,
not sure of that one) and is even the father of OOP. It has in general
quite a few properties that make it interesting from an engineering
and craftsmanship perspective:
- it is amenable to rigorous reasoning, whether formal (eg. Coq
theorem-proving) or informal (simple equational reasoning),
- it emphasizes a key aspect of engineering: compositions and reuse
at each and every level through the all encompassing concept of
function (something that object or class never managed to achieved as
they cannot live in isolation without the concepts of message or
instance)
- it allows one to work with very strong type system (eg. ML,
Haskell, Scala) that provides safety at compile time or lose ones (eg;
Erlang, clojures) that provide dynamicity, extreme feedback and
ductility
- it is most of the time extremely easy to parallelize either
explicitly (eg. scala's actors, erlang's processes or Haskell's STMs)
or implicitly (eg. parallel haskell) which is something quite
interesting those days where multicore CPUs and map-reduce cloud
computations are becoming mainstream
- it eases most of the time writing clear, concise, elegant and more
importantly domain-focused code thanks to its uniform abstraction (eg.
function once again).
In the first page of the SEMAT site there is not even mention of
something vaguely related to language. Methods, tools, principles yes,
but language no. Any "engineering" effort which does not seek to
address the way we speak about our problems in code nor what code
communicates is fraught with great perils. Remember the babel tower of
CORBA ? What is the real-world impact of UML2.X (forgot count after 0)
? What is the most interesting part of the Art of Computer
Programming: the MIX programs, the mathematical and algorithmic
knowledge of Donald Knuth, the beauty of TeX typesetting ?
If I understand correclty the word craft (I am not a native english
speaker) this is an activity that is at the intersetion of art, skill,
knowledge and practical usefulness: A cathedral is crafted, a
blockhaus is engineered. And writing software is 50% software and 50%
writing. Software engineering will never be engineering: As much as
the analogy between factories and software building is false, the
analogies between various kind of engineering and software development
fall short of explaining what's going on with software. To me SEMAT's
initiative is nothing more than another manifestation of software
practitioners inferiority complex towards "true engineers". This does
not mean we should abandon science (or more precisely mathematics),
just that we should stay true to our nature:
SAY IT LOUD ! I HACK AND I'M PROUD !
And to loopback on the beginning of this post, we should say it
functionally. :-)
Best regards,
Arnaud Bailly