Archive for November, 2008

November 12th, 2008

Freedomware needs more engineering and less mere “development”

I am absolutely convinced that freedomware requires less typical development projects and more engineering projects. To overtake freedom-trampling software, we need more than a good philosophy, the best hardware support, cutting-edge technology and money — we need engineering.

We have a lot to learn from the freedom-trampling industry is this regard (possibly, the only thing that is worth “porting” to the freedomware environment). In that industry, software process standards (like CMMi or ISO 12207) are widely used and often a requirement. And we need them here too:

  1. We have more people working together and commonly they are from different countries. Diversity is enormous. So, we need standard, comprehensive and proven mechanisms to handle the software process.
  2. Nearly all of the freedomware projects are mere software development projects, not software engineering projects (and that’s a huge difference!). The wide range of bad practices extends from lack of proper in-code documentation to unrealistic deadlines, including no way to keep track of users’ satisfaction (specially of those who don’t speak the lingua franca of technology). This is, free software is rarely measured (and that, using our own terminology, is a “blocker bug”).

That a given project is community-driven with no full or part-time developer is not an excuse not to measure the software they create. It’ll certainly take time to learn what and how to measure (depending on one’s responsibilities) if the person is new to software measurement, as well as time to analyze the relevant collected measures periodically, but rest assured that by basing your estimations and decisions on such an periodical analysis, the continuous improvement of the project would be guaranteed.

Of course, not every freedomware project “must” be a software engineering project. Tiny projects aimed at a very limited audience and maintained by a couple of developers may not require such a care, specially if it’s not expected to grow too much.

Unfortunately, it’s worth noting that there’s a drawback of using standards like the ones mentioned above: They (usually) assume a software development process like that of non-free software, so you’ll frequently encounter (much) text specific to such processes; and as a result, many processes specific to freedomware development are not covered. I think we need an standard that addresses our software development processes.

Learn more

As in the previous article on software measurement, I recommend the book “Software Measurement” by Christof Ebert and Reiner Dumke (ISBN: 978-3-540-71648-8). As I said previously, it’s a must-read, although it’s perhaps specially aimed at decision-makers and not too much at developers themselves.

Another good book on this topic, which is more practical (as its title implies), is “Software measurement and estimation: A practical approach” by Linda Laird and M. Carol Brennan (ISBN: 978-0-471-67622-5). This one is definitely aimed at developers themselves.

If I reached my goal of making you interested in software measurement in freedomware, then you may also want to keep an eye on the upcoming ÉcoleCua project.

Finally, I invite you to check out, a gratis and basic metrics service for freedomware projects.

November 10th, 2008

Are you a Software Developer or a Software Engineer?

(Practice has changed my view on the subject since I wrote this ranty and simplistic post. By 2010, the most significant realization has been that there’s no such a thing as “Software Engineering”.)

Tired of the indeliberate usage of the term “software engineering”, where “software developer” and “software engineer” seem to be exchangeable, I’m writing this article to explain what I think Software Engineering really is.

But first, let’s remember some basic terminology:

Anyone who can create a program in at least one programming language, regardless of the use of a systematic approach (if any).
Software developer
A software developer is a programmer who doesn’t only care about about simply writing code, but also cares about (although may not be directly involved in) the requirement analysis, the functional specification, the design, the testing, the deployment and the maintenance of the software product they work on. Disciplined software developers usually follow a software development methodology, like XP.
According to the Wikipedia (bolds are mine): “Engineering is the discipline and profession of applying technical and scientific knowledge and utilizing natural laws and physical resources in order to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective and meet specified criteria.”

Both programmers and software developers qualify the software progress. They can’t often meet deadlines nor track process because they don’t know for sure where they are nor where they should be. Qualification is subjective and absolutely imprecise, so you can only have subjective and imprecise answers to precise questions like “when it’s going to be ready?” (to which the most common answers are “soon” or “when it’s ready” in the freedomare world).

When you travel by car, what can you do to find how far you’re from the destination and how much time is left? You have to measure. If you find a sign that states that you’re 20Kms away from your destination and you measure the current car’s speed (well, your car does so for you) and it turns out to be 60Km/hour, then you’ll realize that if you keep the speed you’ll arrive in 20 minutes. If you don’t measure, you can’t tell if you’re on time and you can’t even avoid getting late next time (to improve, you need to know the previous measures!).

If you quantify, you will find the real status of a given process and whether you’ll reach your goals within the desired parameters (time, money, etc.). If you quantified and analyzed such measures, you will be able to execute the right corrections in order to improve the process and thus reach the goals within the desired parameters, or at least reduce the difference between the desired parameters and the final results (this is, reduce risk). And that’s not specific to software.

So, the difference between a disciplined software developer and a software engineer, is that the former qualifies and the later quantifies. In a software engineering project, when a process is going wrong, it’s found (the sooner or later) thanks to software metrics (or “software measurements”) and the appropriate steps are taken to reduce risk. In a software development project, the process is not measured and software product is delivered out of at least one parameter (over-budget, with less features, after the deadline, etc.).

I don’t think you need a diploma that says you’re a software engineer (or hold a position ending by “Software Engineer” in a organization) to call yourself “software engineer”, unless required by local law. But you need to be a disciplined software developer who measures the software process and make decisions based on an objective analysis of the relevant measures.

Learn more

There are good resources out there to learn more about software measurement. The one I strongly recommend is “Software Measurement” by Christof Ebert and Reiner Dumke (ISBN: 978-3-540-71648-8). This book is a great introduction to software measurement and covers the four kinds of software metrics (project, process, product and people metrics). I think it’s a must-read for anyone involved in software processes and wants to improve continuously (which can only be achieved by measuring!).

But there are also good resources on the Web, like the ones listed below. Unfortunately, I couldn’t find something like the book above, but online.

1 Comment »

  • About the author

    You're visiting the technical blog of Gustavo Narea, a Software Developer based in Oxford.