Vainolo's Blog

Archive for the ‘research’ tag

Book Review – Thinking, Fast and Slow

leave a comment

51oXKWrcYYLContinuing on the subject of human behavior (started with this book), I finished reading Thinking, Fast and Slow, by Nobel prize winner Daniel Kahneman. What a great book!


His main idea is that our cognitive functions are executed by two different systems: The first one (system 1) is automatic, fast, doesn’t require much energy, and isn’t very exact (to say the least). The second one (System 2) has to be called explicitly, takes a lot of energy, and its results are much more accurate than those of system 1. This by itself is very interesting, but on top of that, we are limited by the amount of time System 2 can be used until it becomes tired and starts making mistakes. And system 2 can concentrate on only one thing at a time, as is shown by the “Invisible Gorilla” experiment. Are we really that dumb???

Read the rest of this entry »

Written by vainolo

February 14th, 2016 at 9:08 pm

Thoughs on software engineering research

leave a comment

The distance between what they teach us at the university and what happens in the real world is sometimes very large. And I can say this from my personal experience as a lecturer in an Information Systems Analysis and Design course at the Technion. I’ve taught this course for 3 semesters (including this). The course teaches model based/driven/whatever analysis and design of software systems using UML and OPM. I didn’t choose the course, it chose me (it is the course my supervisor teaches it, him being the creator of OPM). We usually divide the course in two, he teaches OPM and I teach UML.

So for the last 3 semesters I have been teaching UML to undergraduate students. And the main problem is that before I was in the academia I worked 9 years as a software engineer (programmer/architect), and almost never found UML to be of any use (except for class diagrams which are really good) Never in my 9 years of work in a big software entity did I see someone create a state-machine, sequence diagram or activity diagram before coding. Nobody though it was useful, not even management.

How can I keep a straight face in front of the students? I can because I believe that there is a problem of lack of abstraction in software development and someone needs to fix it. But is UML modeling the solution? If UML is promoted by so many academics and companies as the solution to all of our problems, then maybe I am missing something. Maybe there is some proof out there that UML does improve software development, that UML is useful.

Therefore I embarked myself in the mission to find this proof by doing a “systematical literature review” of all works that have tested the “usefulness” of UML either by experimenting with mice (i.e. undergraduate students) or in the industry. I search the main publishers of software engineering articles (IEEE, ACM, Springer) since 2005 (year UML 2.0 was introduced), read 3000+ titles and probably half the amount of abstracts to filter these articles, reducing the number of possible matches to 223 articles. Now I am fast-reading the articles to see if they are really empirical or their title/abstract was misleading. So fat 70/114 did do some empirical evaluations, but most of them between “variations” of UML. But I still haven’t found what I’m looking for, which is real evidence that UML does improve software development (there are 2 industrial projects where the usage of UML was seen as beneficial, but that is NOT proof). And I am really skeptical that I will find any proof.

WOW! This post just went in a completely different direction from the one I wanted it to take… I started writing this because of something I read a couple of weeks ago about the distance that exists between the academia and the industry in software engineering. I guess my view is like theirs, and I wanted to add my personal touch.

Oh well, back to filtering UML articles :-)


Enhanced by Zemanta

Written by admin

December 12th, 2012 at 8:15 pm

If mice could program: Some thoughts on software engineering research

leave a comment

One topic that interests me a lot is software development. I also do research on this topic (in my PhD), but my interest is not new and goes back to my first management meeting. In this meeting, my boss showed us lots of graphs showing how me managed to catch bugs early, and how this reduced the cost of the project, and so and so… Nice things, but I thought it was problematic to say that the project was well managed since we deployed the system about 1 year late and with many features not implemented. But my manager, who was a genius at making all kinds of bugs found at each development phase/requirements changed each iteration/etc, thought that this didn’t matter because we delivered a very good working product and that is what mattered. I though differently. But could I prove this in some way?

And this problem of “proving” that one methodology for software development is better than the other still hunts me. “What is the problem?” you are probably asking yourselves. “Obviously agile is better than waterfall, and OOP is better than functional”. But is it really that way? Ambysoft, Scott Ambler‘s company has done a number of surveys (2007, 2008, 2010, 2011) which clearly show that the success rate of iterative and agile projects is higher than for waterfall projects. But, and this is very important, this doesn’t mean that all agile (or iterative) software development is inherently better than waterfall! Why? because correlation does not imply causation.

How could we scientifically prove that agile is better than waterfall, or OO is better than functional? easy!: by doing structured experiments and comparing the results. For example take the requirements of a system, take two teams of developers, let one team implement the requirements using agile and the other using waterfall. Repeat the experiment enough times until you have enough data. Write a paper with your results. Receive a PhD. Easy, right? No… very, very hard.

First of all, to get good experiment results, the two groups would have to be fairly similar. But how the hell do you get two “similar” groups of (real) programmers to invest so much time and effort only for the sake of research? And there is no such thing as “similar” groups! The difference in skill between programmers does not distribute normally – picking a random set of programmers and dividing them in two groups will not give you two similar groups (I had a paper that showed this somewhere… still searching for it). Just one Linus Torvalds, Doug Lea, Joshua Block or similar programmer in one of the groups and your experiment is completely screwed.

But assume that you can find the developers and they are divided equally. You must also check different project types: projects that are very UI centered will surely behave differently than server-side projects with strong algorithmic requirements. More variables you must check.

So what do we do in the academia? we experiment with students. But sadly, students are not real programmers, and they are not developing real world projects. So our results, while great for publishing purposes, are most of the time not representative. And that is the reason why I think we should teach mice to program. If we achieve that goal, we could experiment with them and finally understand how we should develop software!

Disclaimer: I think agile is a great development methodology, but waterfall is also good if implemented as originally proposed by its creator W. Royce, with backtracking when necessary. He even wrote “I believe in this concept, but the implementation [no backtracking]… is risky and invites failure”

Enhanced by Zemanta

Written by vainolo

November 22nd, 2012 at 12:38 pm

%d bloggers like this: