Functional tests and flakyness

I just stumbled on a nice article that Martin Fowler has had on his website for a few years about non deterministic tests. It’s a good read and it addresses something that I have encountered in multiple projects. Flaky test are indeed a problem in many places and I’ve had the ‘pleasure’ of dealing with such tests myself on a couple of occasions (often of my own making even).

Martin Fowler lists a few ways to mitigate this problem and his suggestions are excellent and well worth reading. But I have a few things to add that are not covered in that article.
Continue reading “Functional tests and flakyness”

Scrum: Agile madness

Like most in our industry I’ve been exposed to agile, scrum and related hypes over the past decade. Unlike most in our industry, I have a little bit of background in software engineering research as well. During my Ph. D., which was in the early days of agile when Kent Beck published his book on extreme programming and I was writing my thesis on software architecture, I had the privilege of seeing a lot of different companies from the inside and talked to tech leads, architects and other leaders across a nice range of companies doing software product development. Ultimately after wrapping up my thesis, I decided that I lacked the experience to speak authoritatively on the subject of software development and moved over to the software industry to get some experience.

Continue reading “Scrum: Agile madness”

Using Git and feature branches effectively

There is a bit of a debate raging in the last few weeks that started when somebody commented on a few things that Martin Fowler wrote about git and using feature branches and feature toggles. Martin Fowler makes a few very good points about how feature branches can cause a lot of testing and integration headaches and lot of people seemed to have picked up on this one and there seems to be a bit of an anti-feature branch movement emerging.

Continue reading “Using Git and feature branches effectively”

Agile methods

Another interesting article by Martin Fowler: The New Methodology (and again I’m several months late). The predecessor of this article in 2000 was equally interesting. In fact it still is. If you have the time, read both of them.

Martin Fowler, Kent Beck, Erich Gamma and other people of that generation have greatly influenced the way I think about software engineering. I’ve been a scholar in software engineering and currently my work at Nokia also involves a great deal of software engineering research. I see these guys as the pragmatic force driving the industry forward. While we scholars are babbling about Model Driven Architectures, Architecture Description Languages, etc.in our ivory towers, these guys are all “stuff and no fluff”. It’s a good thing to once in a while consider that many of the software engineering research community ideas and concepts in the past have done and continue to do a lot of damage. For example, the waterfall model (the mother of all software development methodology) is still being taught in universities. Out of touch SE teachers still teach their students to do things one after the other (instead of iteratively).

The original papers on the waterfall model, iterative development and related methodology from the seventies are an interesting read. Their authors had a lot more vision than past and present proponents of these methods. But they are just that: the vision of software developers coming out of the cold in the seventies. We’ve learned a lot since.

If there’s one thing you can learn from Martin Fowler, Kent Beck or Alistair Cockburn, it is that you should never ever implement their methodology to the letter. If you are doing so, you didn’t get it. Agile is all about change, including changing the way you work on permanent basis. The article I’m citing presently argues this in Martin Fowler’s usual clear fashion. Go read it already.

Intentional Software

From a very interesting article by Martin Fowler:

I’ve had the opportunity to spend a little time with Intentional Software and several of my colleagues at ThoughtWorks have worked closely with Intentional over the last year or so. As a result I’ve had the opportunity to peek behind the Intentional curtain – although I’m restricted in how much I can say about what I saw there. Fortunately they intend to start opening up about their work over the next year or so.

Whoohoo! I’ve been following the developments around this company for a few years now. Charles Simonyi is mostly known for being one of the influential architects at Microsoft responsible for creating and popularizing such things as WYSIWYG editing, Excell and the Hungarian notation. Simply put, the guy is brilliant. A brilliant guy with a vision: intentional programming/software. Working for Microsoft from the beginning, he is one of their richer Microsoft millionnaires/billionaires ™. A few years ago he quit his job at Microsoft to start his own company called Intentional Software. Before that he published a few articles on intentional programming which, frankly, include some ideas that are way beyond the imagination of the average C/C++/Java/C#/whatever programmer. While these guys fight over such petty things as syntax, he made it a first class entity in his programming environment. Intentional programming is all about translating intentions to working code. If doing C++ style templates is your intention, define them in the core constructs provided by the intentional programming environment and write them.
But what am I doing, trying to summarize Martin Fowler’s excellent article into one paragraph. Go read his article. It will take you some time but it will be time well spent.

I’ve been a long time fan of Martin Fowler. I should check his site more often.