Archive for category Software Engineering
This is a blog post about an interesting development in the world of software engineering. The formation of the SEMAT –Software Engineering Method and Theory. This is group of being formed by a number of luminaries of the software engineering world. The following is the groups call for action.
Software engineering is gravely hampered today by immature practices. Specific problems include:
- The prevalence of fads more typical of fashion industry than of an engineering discipline.
- The lack of a sound, widely accepted theoretical basis.
- The huge number of methods and method variants, with differences little understood and artificially magnified.
- The lack of credible experimental evaluation and validation.
- The split between industry practice and academic research.
We support a process to refound software engineering based on a solid theory, proven principles and best practices that:
- Include a kernel of widely-agreed elements, extensible for specific uses
- Addresses both technology and people issues
- Are supported by industry, academia, researchers and users
- Support extension in the face of changing requirements and technology
Why My Interest?
The need for an “engineering approach” to software development has long been a topic of conversation in my professional life. The conversations were never contentious, almost all participants have been in agreement. Probably, because I’ve been in discussions with people who can see that this is a real problem in the software development process.
Anyone who has thought about the processes of software development can see that most of what is done is more like a “cottage industry”, rather than an industrial, or engineering process. There is a lager amount of “by rote”, what worked last time, it looks like a good idea, in software development, not much which is founded in rigorous theory.
In part this is because software engineering intersect with economics, and sociology. The process of project management is something which can be viewed as an economic interaction of a number of actors in a closed system. There are all of the classical economic elements, money (costs, salaries, and the like), and resources (developer skills, manager skills, software development tools, and more). Sociology, in that there are human interactions, expectations (what manager does not attempt to manage user expectations), emotional reactions (show me a developer who has not said “I like programming language X”, or “I hate programming language Y”). I myself have cited my sense of aesthetics when evaluating the appropriateness of a design, solution, or class.
I’m particularly fond of the analogy of my software engineering being like master craftsman. In that frequently, I build my own tools, and I follow the “accepted wisdom”. There is some underlying theory in the process, but much is more by rule of thumb.
Establishing a solid theoretical basis for the process of software development is long overdue.
Will the efforts prove fruitful? Well that a question which only time will tell. I’ll be watching the site to see what comes out of the efforts.
It’s a wonder anything works! From :- OMG Ponies!!! (Aka Humanity: Epic Fail) – Jon Skeet: Coding Blog
It’s a wounder that computer system works!
The above blog post is a very interesting read. It highlights a number of fundamental areas of computing where reality and the computing world don’t “see eye to eye”.
Put simply computers work in base 2 numbers (binary). Humans work mostly in base 10 numbers (10 finger and thumbs). Although there are vestigial remnants of other counting systems. A base 12 counting system being the most notable. Remnants of that system include:
- a dozen as a unit,
- a gross as a unit, and
- eleven, twelve as counting separate concepts.
But, when one puts decimal counting (base 10) into a binary world (base 2 – in the computer), all sorts of “bad” things happen. Representation and rounding problems being the most notable.
Dates and Times
A world of pain and problems. We humans seem to navigate this with a maze without too much problem. For computer, or more to the point designers of computer systems infrastructure the following cause a world of pain. These problems include:
- Time zones, we have more of them than you can poke a stick at. Some of which have the same acronyms, but different offsets from UTC.
- Daylight savings, we have different rules in different jurisdictions. Some of these rules for daylight savings being on, or off, are arbitrary in the extreme, and don’ lend themselves to being expressed in a way computers can interpret, and apply.
- Leap seconds. Another one which may, or may not, be supported.
Another world of pain, when on scratches the surface. Making computers work around the world in every language has built into the system more complexity than one can fully understand. Unicode, whilst offering the ability to represent everything, comes with many subtle rules, which a deep knowledge of is required to understand.
- It is a wounder that anything on a computer works. Given the fragile state of the underpinnings, it is little wonder that sometimes things break, or crash, or behave in unusual ways.
- There would seem to be a set “edge cases” or “corner cases” which software should be tested against. The how’s of this concept I’ll cogitate upon.