Software Artist

Following my article about customer satisfaction as a third commitment, I read many articles and thought a little bit about this fixed-price thing. Actually it’s quite funny because the software development industry is about 30 years old at least, and it seems we are just starting to wonder why fixed-price projects don’t work with software the way it works in other industries. And I really think it all started with the Agile Methodology hype because now we’re trying to be pragmatic, we’re trying to embrace the constraints of software development instead of hiding them under the carpet. And one of those constraints is this damn iron triangle.

It’s funny to see how people hold on to it, including both customers and salespersons. It’s like they don’t dare to change it. It’s like they are afraid of changing this model. The problem is that each commitment in this triangle involves a substancial risk that no one is willing to take. But what I realized a few minutes ago after reading this very interesting article is that the reason why it’s really not working is because we’re definitely trying to force a cube into a triangle hole! There’s a commitment we’re constantly forgetting: quality! Whether you like it or not, quality is not something implicit, it’s not even related to the developers on the project. Every experienced developer knows that you can’t code with quality, you have to test it.

My father has been working in a car gearbox factory for over thirty years and I’ve worked there during a month as a summer job when I was a student. And my father is a gearbox tester: a box comes in, it’s set up on the bench, my father goes through first, second, third, fourth, fifth and back down, he listens to the noise that the gearbox is making, and if there’s a problem, it goes back to repair. He does that when the box is finished and the proportion of bad boxes is pretty low, because quality is enforced all through the production line by very careful processes that involve as less intelligence as possible. That’s one or the reasons why robots replace human beings in those factories. Because robots don’t think of their kids or dream of their wife. They just do what they were told to.

Do you really think that this kind of quality can be enforced on a software development project? Of course not! It’s far too intellectual and creative to allow such low-level considerations. And yet I’ve heard tens of times this stupid expression: “software process industrialization”. Come on!

The truth is that the only way to enforce quality on a software project is to test it permanently. To test it automatically, functionnally. To test robustness, scalability, reliability, security, performance. And of course you have to review a lot to ensure that the code remains readable, maintainable and flexible. Software quality can be all of that, and enforcing all those aspects is very time-consuming. It takes some time and some special resources as well. You can’t just forget about that.

So we’re left with four risks: scope, budget, resources… and quality, leading us to four commitments to force into our contracts, right? Wrong! Because there’s something that we’re forgetting: those 4 constraints are changing over time. So here we are, trying to force a irregular and mutating cube into a predetermined and unmodifiable triangle hole. And customers still wonder why it doesn’t work?

…and then you’ve got Management. That’s the main idea I remember from the excellent university presentation I attended this morning at Javapolis: the Zen of Agile Management, by David J. Anderson.

When the guy introduced himself and told us that he was working for Corbis, privately held by Bill Gates, a great deal of worry went through my mind because since the management fiasco with Vista, I don’t really see Microsoft as a reference in terms of agile project management. But then I remembered that Ken Schwaber has worked for Microsoft too. And it took Mr David only a few minutes to remind me that you can’t judge such a big company by only one of its mistakes, even such a big one.

First of all, it’s the first interactive presentation I’ve attended at Javapolis. Sometimes people can get a little disturbed when you ask them to bring their own content into the presentation. But at Axen, that’s something we are really promoting in our trainings, so we find it far worse when we do nothing. Here, there were 4 or 5 exercises that the audience were asked to do collaboratively. We gathered in groups, and discussed given topics and after 5 minutes, he came back to us with a microphone and we talked about what we had come up with. Interesting idea, especially for such a 3-hour presentation with such a big audience.

That was for the “layout”, now for the content.

There were really two parts in this presentation: first you’ve got Agile… and that was the main point of interest for me. First of all, he insisted on the importance of trust with knowledge workers, defining knowledge workers as people who know how to do their job better than their bosses do. And I love that definition. The thing is that sometimes it’s difficult to forget about the traditional role of a project manager, to remember that there are better ways to have visibility and control over the project than micro-management. And it’s even more difficult to limit yourself to just being a facilitator rather than a leader, to get out of the way when the team doesn’t need you and be there only when they do. That’s what a Scrum master is all about. And trust is obviously the basis for it to work.

I also saw a couple of very interesting usages of cumulative flow diagrams, reporting artifacts that I have never used before, but which give some interesting information. The main point there was that the best way to optimize your interventions as a Agile project facilitator is to consider a few metrics, but only the good ones, the best one according to him being the Lead Time, in other words the time it takes for a feature/task/use-case/whatever to go through your workflow from start to end. The thing is that if you implement things faster, you see bugs earlier so there are less of them, so you lose less time fixing bugs and you do things faster, and the virtuous circle goes. And how do you implement things faster? Simple! Do less in parallel. That’s what of the main things that I loved about this presentation: David destroyed many common beliefs, and at that moment, the way he explains this, it seems obvious. And it’s only when you think about it for a minute that you realize how most project managers do things the wrong way.

The second part of the presentation was more about making decisions at a higher level, analyzing metrics, identifying bottlenecks and reacting properly with surgical interventions. Sometimes I was a bit lost with all those numbers but it made it obvious to me that there should be more project managers at conferences like this. One of the exercises was about identifying the bottleneck in the project we’re currently working on, and what we would do about it now that we have some leads. I know exactly where the bottleneck is on my project, but what am I gonna do about it? That’s another question.

… But it’s not!!! Since the beginning of my career at Axen, I’ve worked for 4 differents customers including the one I’m currently working for. And it always amazes me to see how difficult it is for them to deal with such a basic need as project management tooling. And apparently, judging by a few discussions I’ve had with a bunch of colleagues in the consulting busines, it’s not only the customers I work for!

The thing is that, even if Agility is gaining more and more attention these days, with tight collaboration and cooperation at heart, most companies out there are still managing their IT in a very procedural way. They have project baselines and plans, forms, excel sheets and time sheets everywhere. Every decision has to go through the proper validation channel, and believe it or not: it’s slowing down their business. All those mandatory procedures create an enormous need for tools that can make it simpler and more effective to create, share and collaborate on project-related information. Source code assets, planning, documentation, issues, releases are amongst the most redundant tasks in IT projects, tasks which need tools like version control systems, wikis, issue tracking, release management, etc.

You could think, where there is such a need, there is a market, and where there is a market, there are solutions available! Wrong! Or to be more precise, there ARE solutions, there are too many of them, and the worst thing is they’re incompatible with each other.

Let me give you an example. On the project I’m working on right now, we needed a version control system. The company-wide default one didn’t suit our Java development needs, so rather than trying to force a cube into a circular hole, we chose not to use any version control system… until recently. Now merging code from all the developers is really becoming a big issue and we are losing a lot of time and money on it. So rather than staying in that situation until a new company-wide standard VCS is chosen, we proposed to install Subversion. And believe me, that’s a huge step forward!

But recently, there was a demo of the application and the project lead noticed a few bugs while using it, a few bugs that he naturally wrote down in a non-collaborative but so common Excel sheet. And now he realizes that, if he wants the bugs to be fixed, we need to have some sort of system to register and monitor those bugs, in other words, an issue tracking system. First integration problem: we need an issue tracking system that is compatible with our version control system so that, when a code change fixes a bug, there is a link between the commit and the issue it fixes. And that of course is totally independant of the fact that we need an issue tracking system that makes it easy enough to register new bugs, so that users and developers are not slowed down on the way.

But wait a minute: now if there is a version control system, and an issue tracking system, everybody has to know where they can be accessed. That and the documentation for the project, like design specifications, requirements, coding conventions, and all the information that the teams needs to know in order to work efficiently. First reflex, why not a wiki? A simple editable website where anyone can create and modify pages with just a few clicks. Sure thing! But hey, it must use the same user base as our version control and issue tracking systems. Are you getting it?

Yes, there are a lot of tools out there, both commercial and Open Source, for version control, issue tracking, documentation management, release management, planning, and so on and so forth. But believe it or not: for each of the projects I’ve worked on in the past five years or so, I have looked for a single platform that could integrate all of those very common tasks into a single consistent environment, something so easy to install, maintain and use that it would just… work! I’m not saying it does not exist, but I don’t see it anywhere, and judging by the amount of time I dedicate to technology watch every single day, I think that if such a miraculous tool existed, it would be everywhere!

Well, you know what they say: if you’re not happy with a situation, what prevents you to change it? In that case, nothing! And that’s why I’m currently working with Axen on such a platform. All I can tell you right now is that it’s called Basement PMS (Project Management System), and I would love it to be open-source. We just have to figure out a few details, and I’m working on a proof-of-concept to show off. But I’m convinced it’s gonna be awesome.

What do you think about that problematic? Have you ever encountered or worked in a company with a single, consistent and reliable IT project collaboration environment?