I have told this multiple times, maybe it's worth a blogpost on its own. It's mainly a reaction to recent posts of Dave West from InfoQ, and the discussions formed beneath them. Although I can feel it through what makes someone to think this way, yet I have different opinions which I would like to tell.
I have been hearing a lot of times about wether what programmers do is engineering, is science, art, or what. When I was about 18, even I had some thoughts that building software is not about engineering, but now, perhaps just because I became a master of software engineering officially (ok, it's called engineer-informatitian in hungarian), I do think it is.
Why does the question arise? Because our daily job - at least, for a lot of us - is not based on science, but rather is about some chaotic finding-your-way thing. It rarely involves drawings and science - not gut - based calculations if you don't explicitly insist on them, especially not in the enterprise world.
Some say 60 years ought to be enough for an engineering discipline to form, and therefore this isn't one; I think it otherwise. I think it will take us a lot more time to find out what this thing is, even if we reached this far, and even if our profession has roots in the ancient Egyptian civilization (have you ever thought of that the basis of Egyptian tax administration is a series of calculatiosn based on water sensors and other aggregated data?).
Let's start with two questions: what is engineering? What is software engineering?
Let me answer the first question with a personal point of view, and a second with an official one.
Engineering is art and science
Engineering is a set of disciplines between art and science; that is, there's no engineering without science; yet it has the elements of art. Most of the time, I will use build-engineering, so, architecture as an example.
I don't believe that architects always knew how to build monumental buildings; I believe that only our later generation thinks that people were sure what to do back then. Of course, a lot of buildings didn't stand out the winds of time. But even those who stand, may be a fortunate result of trial and error, rather than a final product of a well thought-out process.
I also believe that the ratio between art and science changes over time and over discipline: modernist buildings, in which a lot of us are living today - at least in Hungary - were more about science. Perhaps bridges are more about science too: it is not really a question how a bridge should look like if it does not stand the tides of the river it is built over.
But software engineering has a bit more of an art: it has merely much more soft parts, hence the name. How rigid are these parts is depending on the given software: however, our whole profession believes that softwares have to be as soft as possible in order to be able to adapt these soft ecosystems they are perceived to be employed in.
Code is the formalization itself
We should also note, that we prefer to hide the hard parts behind libraries. Code is nothing else but formalization.
Some may argue that even data is formalization of the information; it may be true.
We see a lot of formal methods turned into code: connecting to a server on the internet is a quite complex task, yet we should rarely think about it; after a few lines, the copy of a textual file from another server becomes a memory block.
One thing that is hard to formalize such way is the creational process itself: of course, we have build scripts and IDEs and GUI designer programs and so on, we may even have program-generators; yet the creational involves a lot of human factors, a lot of uniqueness for the given situation, that even if we have formal methods for that, we should decide on a per situation basis what to apply.
Engineers work for communities of human beings
I also believe, that engineering is about creating things which are a part of a human system: that is, there's no real building without human use; waterpipes are built for humans, buildings, bridges are mostly for humans.
It is interesting to note, that engineering is nearly always about supporting communities: building houses is rarely about a single person, but a community of people living, using the building over a long period of time. You also wouldn't create a waterpipe system for just one person except for the really luxorious ones: they mostly support a neighborhood.
Software engineering, in a good sense, is also about supporting the needs of a group: the group of your end-users. People involved in the process are rarely part of this group: the customer for, let's say, a webshop is not the customer who will use that webshop, but rather the head of the company which attempts to sell goods in it; in some cicumstances, those won't be even its administrators.
So what is software engineering?
Let me quote the SWEBOK
The IEEE Computer Society defines software engineering as: "(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)."
It does not say software is a science: what it does say, that:
- Software has patterns, therefore systematic solutions can be used for common situations
- Software can have methods to build, that means, there could be a discipline to build software
- Software has numbers associated with it (like: resource used, speed), therefore it can be measured, and optimized for it.
Let us say that while these may be argued in general, in specific cases they would be hard to argue: I honestly think, for example, that most webpages have a notion of menu, and I start most of my homepage desings systematically with a logo and a menu, even if that logo is textual.; also, over the years, I have developed systematic solutions for solving certain web development needs; for some, I have automatic tools, for others, not yet. And I believe any of us could measure the loading time of our favourite social network, and a lot of us could argue about its acceptabilty :)
Also let us put software engineering back in context: traditionally, software engineering is traced back to the 1968 NATO conference.
What they realized in 1968, is not only that our - back then - current way of creating software is a chaotic mess; they realized, that it is expected that we will need to write a whoole lot of software, not just necessarily for military purposes.
And we do write a lot of software: every day, dozens of facebook apps, iphone apps, homepages surface, not to talk about embedded softwares from cars to microwaves and beyond.
Software engineering is not about building exceptional software: doing something exceptional is always more an art than a science. It is about building good enough software in general.
May we failed in a large scale, as some say, we are mostly succesful in the middle scale: any of us could create a blog in the order of minutes; of course, we would use pre-built software for that - like, wordpress - but that would be less about creating new software but reusing something existing.
Also, we didn't really fail in the large scale: we successfully applied some theories and metaphors which we use in our everyday lifes: any of us could build a list-based component in their favourite system of choice, for example. Every programming language in mainstream use is a succesful generalization of concepts in itself.
On small scale, it's still questionable whether we will be able to win. As Boochs, one of the authors of the UML and the pioneer of using classes and "inheritance" as a basis of our analysis said:
Software is inherently complex.
As an example, today I had to analyse an account locking mechanism: at first, it seemed simple: accounts should be locked if wrong password is tried more than five times a row; but we realized, that they should be locked even if the last password set is more than half a year old; then we realized that we need different behaviour in case the account is locked for different reasons.
What seemed simple in the beginning became complex in a few minutes just by talking about the requirements; the simple drawing started to explode.
We still don't understand these enough and, until then, software projects are subjects of being late or being broken.
Conclusion
So, we are part of a young discipline. What we should understand is not only the world surrounding us; we should understand to take the right directions. This is our responsibility, as part of the early generation.
No comments:
Post a Comment