Taking software engineering seriously

re: Taking software engineering seriously

tadanderson — Wed, 11 Jan 2006 19:38:27 GMT

I like why it is important to you. Engineering is the only why to give an application a future.

I wrote a small blog on what I see the difference between .net software development and software engineering is.

[http://realworldsa.dotnetdevelopersjournal.com/net_software_engineering_versus_net_software_development.htm]

re: Taking software engineering seriously

tadanderson — Wed, 11 Jan 2006 19:39:19 GMT

For some reason te link to the blog didn't go through. Trying again..
http://realworldsa.dotnetdevelopersjournal.com/net_software_engineering_versus_net_software_development.htm

re: Taking software engineering seriously

marcod — Wed, 11 Jan 2006 19:58:02 GMT

Talking about software engineering in general.
So should we pretend it is a full-fledged branch of engineering? Or could be better to avoid wishful thinking?

re: Taking software engineering seriously

tadanderson — Wed, 11 Jan 2006 22:10:54 GMT

Well I think it is a branch of engineering in certain circles. When I worked an electronic engineer the software we wrote to program our PLCs (PROGRAMMABLE LOGIC CONTROLLERS) was engineered just like the components that went in to the hardware.

In the domain of applications built for computers (web apps, windows apps, enterprise apps) I know it is possible to do, but is for the most part rejected by organizations building the software. I think it is mostly because a lot of them have been introduced to building applications with tools like VB 6.0, and other IDEs that promote RAD development. Which is a good thing when considering time to market, but a bad thing for maintainability, quality, and building applications that actually meet the requirements of the client. It is basically building an application that is a legacy application the day it is released. By legacy I mean you don't know how it was built, so it will be difficult to modify, maintain, debug, and upgrade.

I know Rational was striving to get us there, but now they are no longer around. They have been swallowed by IBM, so I don't depend on them as a resource for what one might call open software engineering. Meaning no one is influencing their goals of improving software engineering.

Currently I review many organizations to extract from them what might be good practices for software engineering. Microsoft, IBM, Sun, Intel, and all those competing in the market. But I am always wary and need to make sure what they are preaching/teaching is not for their own hidden agenda that is market focused. I include all the open source projects in this group also. I always like to do what Microsoft and these other groups do internally, but I find a lot times I avoid doing what they are telling the market to do.

I trust a few sources without hesitation and they are the Carnegie Mellon Software Engineering Institute (SEI), Massachusetts Institute of Technology (MIT), and Institute of Electrical and Electronics Engineers (IEEE).

It is being done is some circles, so I would say that qualifies it as a branch of engineering. It just isn't being done nearly enough.

Engineering needs a process. I talk about that here: http://realworldsa.dotnetdevelop ersjournal.com/the_process_ladder_up_rup_eup_ple__ never_neverland.htm

re: Taking software engineering seriously

marcod — Wed, 11 Jan 2006 22:34:34 GMT

A systematic method for software design is a very good thing, disciplined and thoughtful people are critical. But I do not see how those are related to the qualification of software engineering as a proper branch of engineering, or for that matter, the qualification of the theories that makes a software science.

MIT, CMU, IEEE are respected organizations, that is clear. Just show me where are the laws of software which support the theories that makes the science behind software engineering, I am looking for them.

re: Taking software engineering seriously

tadanderson — Wed, 11 Jan 2006 23:09:42 GMT

Your base is this:
If we took as premise that all engineering is applied factual science (unlike formal sciences -of which there are no applications for the very reason they are formal), and the sine qua non attribute for a science to exist is that it is made of theories; and each theory is a system of laws; and each law is a general, necessary and constant relationship between phenomena (observed facts); and the observed facts can be perceived with the senses and repeatable…

The process (UP, RUP, and so on) defines the laws. The laws are what keep the humans in the process repeating actions that provide a predictable outcome.

The same way a process defines how an engineer builds an electronic component. The laws of software engineering are govern by the laws of electronic engineering. Combined they create computer science.

The book CODE by Charles Petzold is a cool read that walks across that bridge.

Who knows, maybe you got a point and we are all living in the Matrix, and I am really just Mr. Anderson thinking a am a software engineer…

re: Taking software engineering seriously

marcod — Thu, 12 Jan 2006 08:14:07 GMT

(Seriously, this dialog is very useful, please keep yourself thoughtful)

It is very hard for me to see a proprietary software process framework like Unified Process or a commercial one like Rational Unified Framework (now IBM Rational Method Composer) to be the laws that explain and predict all software development of the world. Try to grab from them in a prohibited way and you will have to face some merciless lawyers very soon.

No, I think we are writing about two different things entirely. As if you were writing about the numbers 23.5 and 12 and I were writing about data types double and integer.

It is very, very hard for me to see how possibly “The laws of software engineering are govern by the laws of electronic engineering”. Just because the goods made out of atoms follow different physical rules in comparison with the goods made out of bits.

Sorry but I think that Mr. Petzold got it somewhat unbalanced between hardware and software, he talks in his book 80% about hardware and 20% about software, to some extend disappointing for me.

So far, as objective as I can possibly be, software development trade by now is like old guilds of artisans, where the most advanced are spreading their knowledge by means of craftsmanship traditions; but very far from establishing reliable knowledge for the basis of a software science, yet.

re: Taking software engineering seriously

tadanderson — Fri, 13 Jan 2006 00:55:23 GMT

But aren't the bits being placed into the atoms constrained by the laws that the atoms are enforcing? And the atoms are being placed together by the laws that nature allows us to structure them. To me the laws are being forced upon the next layer of abstraction - the chip's physical structure -> the electronic storage into the chip -> the bits arranged to form digital communication patterns that move through the layers of language abstraction for assembler to C to IL to C#.

re: Taking software engineering seriously

tadanderson — Fri, 13 Jan 2006 01:20:33 GMT

These two links provide some interesting perspectives on the point you are raising.

http://en.wikipedia.org/wiki/Software_engineering

http://en.wikipedia.org/wiki/Software_Craftsmanship

The second says this about the topic:

While software engineering appropriately describes the processes necessary to build large, complex systems like those at work doing tasks like flying the Space Shuttle, software craftsmanship as modelled after the guild tradition in the building trades is in fact how the bulk of software is actually written.

Which I would agree with.

re: Taking software engineering seriously

tadanderson — Sat, 14 Jan 2006 16:17:30 GMT

My final post on this is here:

http://realworldsa.dotnetdevelopersjournal.com/net_software_engineering_versus_net_software_development.htm

re: Taking software engineering seriously

marcod — Sun, 15 Jan 2006 06:29:53 GMT

You keep using the word “engineering” but by now I am lost of your intended meaning.
The intended meaning on my original post entry is that engineering refers to the applied/practical/functional/workable part of some established body of scientific knowledge (that is to say, reliable knowledge built on theories whose use is to explain and to predict a part of our world), in this case about design of computer programs.

No amount of people-no matter how large-yelling and repeating "the sun goes around the earth", make it so; or as Mr. Lincoln said: "If you call a tail a leg, how many legs has a dog? Five? No, calling a tail a leg don't make it a leg" -Abraham Lincoln

Telling a human activity is a branch of engineering discipline should be based on more than "it feels as engineering" or "it ought to be engineering", which is basically what was said at the 1968 NATO conference where the term "software engineering" was originally coined*.

Where are the corresponding theories since then?
It is perhaps that marketing people has done a better job than us in our mainstream trade?

*The End of Software Engineering and the Start of Economic-Cooperative Gaming
http://alistair.cockburn.us/crystal/articles/eoseatsoecg/theendofsoftwareengineering.htm

Some thoughts:

"Q:What are the most exciting, promising software engineering ideas or techniques on the horizon? A:I don't think that the most promising ideas are on the horizon. They are already here and have been for years, but are not being used properly" -David Lorge Parnas

"Computer science hasn’t achieved the grand narrative that explains it all, the big picture—we haven’t found the fundamental laws of software that would play the role that the fundamental laws of physics play for other engineering disciplines" -Philippe Kruchten

OK, So Maybe Software Development Isn’t Engineering After All
http://mcpmag.com/columns/article.asp?editorialsid=1120

re: Taking software engineering seriously

root123 — Fri, 06 Jun 2008 11:43:54 GMT

At macro level it may be termed something other than engineering....

re: Taking software engineering seriously

hxa7241 — Sat, 03 Oct 2009 13:24:07 GMT

This is a well-made analysis of the question, which is commendable when so few others are as careful. I think I can answer in reasonable way.

Looking one step further, we may ask: what is it that enables scientific laws to be formed? It is a basic material that is substantially determinate -- that behaves sufficiently 'regularly' as to be amenable to logical, mathematical models being made of it.

Does software have such a material? Yes. Looking at the very lowest level, there is the bit with its properties of identity and mutability. It is necessarily entirely determinate -- it is in a sense made of the same stuff as a model itself. Now, although this medium is clearly adequate for laws, does it have any? Algorithmic complexity results must count -- e.g. comparison sorts having minimum O(n log n). They are substantial, useful, and measurable. Yet there still seems a lack of such solid laws generally.

So software certainly has a core of the type of an engineering, it has the potential, but it has not been fully realised. Software seems best described as an immature engineering -- something often felt, but the above gives a rational account of why.

For more, see:

http://www.hxa.name/articles/content/building-model-for-software_hxa7241_2009.html

http://www.hxa.name/articles/content/software-engineering-and-civil-engineering_hxa7241_2008.html