Auswanderer Quatsch

What if visual studio had achievements? How goofy would that be? Can you imagine the teaching potential of such a tool? Here are some of the best achievements the orginal author of the article imagined… and some more are to find in the comments:

• The Mathematician – Defined 15 local variables with a single character name
• Spaghetti Monster – Written a single line with more than 300 characters
• The Organizer – Created a Solution with more than 50 projects
• The Portal – Created a circular project dependency
• The Multitasker – Have more than 50 source files open at the same time
• Pasta Chef – Created a class with more than 100 fields, properties or methods
• Procedural Programmer – Created a method with more than 10 out parameters
• The Poet – Written a source file with more than 10,000 lines
• The Enterprise – Build Solution took more than 10 minutes
• The Architect – Created 25 Interfaces in a single project
• The Right Way – Test method is longer than the tested method
• Pokemon Programming – Caught all the exceptions
• The Cloner – Copy-pasted more than 50 lines
• Every Option Considered – Created an enum with more than 30 values

… and that’s when I start browsing the VisualStudio Extension API…

One step we are now trying out is “XP programming” and furthermore “pair-programming”. The idea behind pair prog’ is that if one can easily fully concentrate on the semantic of the programming language or on the design of the code on his own, doing both at the same time is quite a challenge. But this can easily be covered by programming in pairs.

Pair programming would have many advantages for us. It would help ramp up out our new colleagues faster than ever. It would help leverage the knowledge gap and increase the collective ownership of our code. It would help spread the good practices brought to us by our Java-Experienced colleagues and help strengthen their habits to fit the rigorousness of C++, it would generally improve code quality and facilitate the hard refactoring we are setting in motion…

The problem is XP is all about communication, proximity… and with our senior dev’ being in Slovakia, we’d have to do some kind of “remote XP”. The first local pair-prog’ sessions we did were so tremendously positive that after one day it was accepted as a new best practice… but I’m not sure how the “remote” part will go.

After two iterations using daily stand ups, I started seeing the premises of what seems to be called “Daily Standup Withdrawal“. The purpose of the daily stand-up isn’t as much about answering the three questions (“what did you do? what will you do? what stands in your way?”) than thinking about the influence their answers have on one’s work… in other words, be proactive.

The daily Standup withdrawal (or whatever you call it doh) is simply the state your team is in when they start using the Standup as a reporting time more than a “team sharing” tool… and the blame is maybe not on their side.

In our team, beside changing the way we work, we are testing some agile tools (no MS-Project here Patrick bytheway :] ) and the tool we currently use (ScrumDesk), used to be at the center of our daily Stand ups. Given that we are doing our meetings via LiveMeeting (one dev is in Slovakia, remember?), I would open the tool on its “sprint panel view”, share my desktop for everyone else to see and we would all play around with the software wile updating the status together. We all did this unintentionally ; and I would actually simply try to concentrate on moderating the talks, looking after the two main ideas 1) everybody talk 2) everybody has a the time to talk.

What I soon realized, is that since the tool is at the center of our discussion, we kind of all concentrated on talking about the topics that are written there… and try to make the tool show some progress. Me typing something would orient the discussion, me opening a panel would break the flow of the person currently talking etc.

The last measures we took were thus for everyone to update their part beforehand and for me not to share anything during the meeting. With the help of one developer who is really into Agile, we somehow managed to put this withdrawal away… for now…

No, not talking about MlleV, not this time… I actually want to talk about methodology, and this starts with the V-Model also called waterfall.

This model is an engineering model used to sequentially cover all the phases of an engineering project and execute, for each phase, a pendant testing/validation phase. This model proved its usefulness in the past and is thus very common in the industry. But it has a major drawback: it hates change… and change we have!

Since I stepped up into my new position and got used to the new field, the processes and the daily work flow, I have been pushing hard to step out of this V-model and start implementing something called “agile” (and I am not alone here) that is exactly thought for this… Agile is a philosophy as well as a methodology, a set of rules and a bag of common sense statements that all tend to one vision: better software that suits the customer needs…

There are tons of books, methodologies, road maps etc. on how to start working “agile”, but from the theory to the praxis there is a gap… and in the middle of it I stand! We actually face two different issues. The first one being the project itself with its huge legacy code base, its constant inflow from the customers (formal complaints), necessary test and validation phases (Class III medical device)… and those are some of the highest risks of failing to implement the agility. And the second one is the people… this involves a deep change of mindset and involves some risks that some are not willing to take. We thus have to prove, show, demonstrate and validate every step we take in order to finally step into agility.

I cannot pretend I’ll be keeping close track of everything we try, but at least for myself I am trying to write down what we do, what we tryout and see how it tends to end up… so why not share some of it with you?

You might have noticed it already: I like to summarize, formalize and explain things… or at least write them down (even graphically recently). Given the opportunity I would/will probably end up teaching… but future will tell

As Software Engineering (SE) is my daily work, you can easily imagine that interrogations about the ways we teach it nowadays are never far from my mind. My studies were not focused on SE per se, but I ended up developing myself / leading development teams and I realize better everyday the enormous gap that exists between the classes I had and my daily work or what I would expect from my junior developers. Multiple times I started writing some of my thoughts but I never liked the posts afterwards, that’s why you never saw them.

Why do I talk about it today then? Simply because a really good article (pointed out by Rolyat on Twitter) titled What should we teach new software developers, tingled my thoughts lately and that I’d like to express my feelings on the matter while spreading the article.

What’s so interesting about teaching SE you might ask? Well, the major one is that SE is a really young subject/art, not yet mature – even in the industry. The comparison is indeed abusive but a non negligible part of the courses I followed felt almost as close to SE as scribbling shopping lists is to writing a science fiction. So there is much to do and definitely not less to say.

Junior developers nowadays were born at the end of the 80s and started programming about 5 years ago facing 20 years of legacy technology built like a exponentially expanding onion. I cannot tell how it is taught in IT degrees since I only have a general engineering degree specialized in IT, but I can tell you how I see it through my fellow colleagues and the students we employ. Universities teach you a lot about programming and using technologies, but very few about SE itself.

I can remember very well a “marketing” sentence of the teacher responsible for the SE major at my university: “I don’t care if you cannot program, that’s not what SE and my major are about anyway”. That is so true… and so wrong at the same time:

• On one hand, Software Engineering is impossible without highly trained programmers. And since programming is the craft of creating software, programming must be the center of the SE studies. That’s pretty much the university point of view. And for that they don’t have any minute to spare since 5 years degrees are already not enough to teach all the technical required knowledge a modern programmer should know.
• On the other hand, ask anyone in the industry, Software Engineering is so many things BUT programming. SE is the art of building a software with delays constraints, quality goals, technology constraints, concurrent engineering, customer satisfaction etc. so many things relying on programming but not programming itself.

Between those two worlds you find newly graduated students sitting between two chairs, unsure of their knowledge, experts in a high-level language but incapable of explaining some key concepts of the layers they rely on and almost totally strangers to the Engineering process and requirements. I was able to enter the world of software development as an engineer specialized in SE, but will it be possible in the future to continue doing so?

There are a lot of open questions. What is really important to know as a software engineer? In all the flourishing concepts that we face everyday, which are the key ones? Which are the hardest ones to understand? What are the subjects that will help the students in their future life and not only to get their first job interview on tracks? Those are the real questions that we have to address, and that is what interest me much ; now I hope you understand why I am very interested in the ways Software Engineering is taught nowadays.