Archive for the ‘Agility’ Category
Change is Happening, my Friends!
I know it sounds like an apocalyptic prediction of some sort, but it’s all the contrary. And I’m not talking about politics, or the big-bang-boom-tada-yeah that’s happening right now in a country north from here. I’m talking about our work environment. I’m talking about how the way we solve our problems is already changing. In his very inspiring presentation, Clay Shirky mentioned a transition, that he saw already happening back in 2005, but a transition anyway. The thing is that it takes a visionary to see such a transition while it’s happening because… well… it’s happening. So you’re supposed to be a part of it. Talk about an out-of-body experience (I don’t know the right expression for that in English, sorry).
And this morning, answering a message from my friend and former boss on LinkedIn, I realized that the signs were right here before my very eyes:
- Organisational: when I was interviewed by Axen, I was seduced by their organisational model, because it was completely original. Pretty flat hierarchy, no “I can’t make that decision, it’s not in my prerogatives” thing, a lot of flexibility and pragmatism, everything is a project and people gather dynamically to implement such projects, they learn a lot, and then they move to something else. Astounding! And it worked… for some time. And now even though THIS instance is being absorbed in the guts of a greedy giant, I know it can work. Or to be more specific, I know that people can work like that. Not everybody, but some people can.
- Technical: have you noticed how the Internet is everywhere in what we do? Have you noticed how it expands our natural limits to bond and share with one another. Am I worried that I might lose contact with all the wonderful people at Axen when I leave? No! I have them all in my LinkedIn account, I can follow them, see how they’re doing, where they’re going, what they’re working on. And more importantly I have a permanent way to keep in touch with them. And of course there are all the people that I’ve met, worked with, thanks to the Internet. There’s Claes, the guy I’m working with on ConferenceGuide. There are all the contacts I’ve met at DMF in October… and the ones I’ve lost, because I didn’t get their card and couldn’t add them to my contacts (Damn it!)
- Methodological: this is more specific to the IT field, but still, it shows that minds are shifting thanks to Agile Methodologies. Get back to what really matters: creating value. Let go of your old beliefs that you’re going to keep everything under control and never change your mind. Our business is moving fast, let’s embrace it. Let’s build trust with our teams, encourage everyone to commit, improve our state-of-the-art. And let’s stop saying things like “people are dumb, and lazy, and short-sighted, so we need this control and methodology”. That sounds too much like a self-fulfilling prophecy.
And there are probably other aspects that are already changing drastically. I’m not saying they’re changing for everyone. Like any evolutionary process, some specimens are trying it, it increases their chances of survival, others die. It’s like work environment natural selection at… work. Now I’m not a Darwin expert, but I’m wondering whether at some point, seeing that some “features” obviously work better than others, nature doesn’t have a way to push those forward. And even if nature is not capable of this, maybe we are. Maybe now that we are aware of those changes, now that we know they work better, now that we are in times when cards are dealt again, it’s time for us to give a little help to natural selection.
I think those changes are still too shy, they look like an archaeopteryx to me (you know this missing link in evolution, sort of half-dinosaur, half-bird). In other words, all those changes are still happening in what seems more and more like an archaic and unfit environment for solving problems: the company. And here I am, envisioning a work environment full of adhocratic-agile-connected people without the need for a constraining and limiting structure full of overhead and politics. I have a dream! But it’s not over yet…
My Discoveries of the Year
Every year, the main reason why I go to Devoxx is to discover new stuff. For me it’s all about technology watch. The internet and RSS feeds are my main tech watch instrument but there is one thing that is harder to get through RSS: feelings. Conferences like Devoxx are a unique opportunity, not only to see what’s happening but also to sense how the community is feeling about it, which is at least as important to anticipate on what’s going to be important.
Now you’ve certainly read here and there that there have been a lot of talks about Java EE6 and Closures in JDK 7. There sure were, and there was quite a lot of reactions to those. But frankly, I’m not interested in any of those. I’m not interested in Java EE6 because even though it finally leverages the concepts that have been pushed by the community for so long, the very fact that Sun has been so late in implementing them shows one thing to me: it’s not about them, it’s about us. Sun has been trying to partner with big companies around the JCP, to create a lot of business around those standards. And why were those standards so complex? Because there were so many companies involved in their elaboration? Or was there any interest from those companies to create technologies complicated enough to require a lot of consultants, and books, and trainings, and tools to make things easier? If the first option is true, then how did it happen that a gigantic community of individual software developers made it so that Spring, Hibernate and other Open Source technologies became de facto standards?
Which brings me to the second point I don’t really care about: closures in JDK 7. People have taken matters into their own hands. Other languages have appeared implementing some of the missing features of Java: Scala, Groovy, etc. Some other languages have been imported into the Java landscape, like Ruby and Python. I’ve been using Groovy myself for some time now, and I couldn’t be happier with it. Now Sun is coming after the war, but does it matter? What I see here is that it’s good to have a base language, a base platform. But as soon as you start extending it for purely mercantile reasons, or as soon as you start avoiding certain innovations because you’re afraid it might harm your business or the one of your partners, then things go messy. But once again, the good news is that software gives us power. We developers have the ability not only to decide which technology is better, but to build and promote our own technologies. And I think this is why our world is so dynamic and why things change so fast. What I see here is that languages matter less than our ability to create new ones, to solve more specific problems, to provide some more advanced features. And that strengthens my belief that Language-Oriented Programming is the next big step in the evolution of our technologies.
Now about the things I do care about. My discoveries.
My first one is definitely Kanban. I’ve heard about it for quite some time. But I didn’t understand why people were already trying to push it forward, even though we are still fighting to push companies away from waterfall messes. It’s even more radical than Scrum and for that it’s very interesting because it gets closer to what software development really is. The key phrase that kept popping in my head during the 3-hour session about Kanban was “It’s going to take the time it’s going to take.” And that’s why it’s brilliant. Now that I understand Kanban a little better, I see Scrum as a compromise. We’ve taken some of the principles of Lean Manufacturing, we have dissolved them into trusted concepts like RUP’s iterative cycles. And for years, we have been trying to pour that cocktail into their mouth. And in doing that we forgot something important: if they don’t trust us, they will never drink the whole thing, all the more so as it looks weird with all those colors not really mixed together. The way I see it, Lean and Kanban are all about getting back to the basics, and relying on trust. We have to build trust first, we have to make them understand that at least some of us are not interested in building artificial business on top of poor practices. That at least some of us desperately want the software we build to have a real impact on their business. We have to show them our good will so that they let us do our job. And they have to understand that the more they trust us, the faster we will be, the more we will be able to solve other problems. Big software vendors and resource providers will not like that, because every new project comes with its own overhead, because their business thrives on poor practices, stupid methodologies and complex technologies. But once again, power is in our hands, it lies in collaboration, not in corporation.
My second discovery was Spring-Actionscript. Those guys really have a thing to do things in a clever way. Cairngorm, PureMVC, Swiz, they all impose some sort of a structure to your Flex applications, forcing you to surrender some great powers of Flex itself in the process. And here comes Spring-Actionscript, more like a toolbox than a real framework. It doesn’t impose anything. It just gives you all the tools you need, all the glue you miss, to make things fit together perfectly. Their asynchronous abstraction is just brilliant, their configuration options are complete, your code just looks better with it, simpler, more natural. I think that’s what I love most with Spring: not only does it create great technology, but it also instigates a whole pragmatic and elegant way of thinking into the minds of a whole generation of developers, thus encouraging the community to come up with their own technologies: Spring Actionscript used to be called the Prana Framework, developed independently by a Belgian guy who took inspiration in Spring for Java. That’s just awesome. I will definitely integrate Spring Actionscript in a couple of Spring/Flex projects. I think I will even update my todolist sample application with it. Stay tuned.
My third discovery is a couple of technologies to detect and prevent coding errors BEFORE they actually happen. I insist on “before” because of my previous post about TDD: unit tests are all about writing code to check that some other code you have already written (or not written yet) does its job. But to me, this is equivalent to the old prevention versus repression debate. TDD is just repression, and it’s tempting to go there only, because it’s always easier to catch the bad guys than trying to understand why they became bad in the first place. JSR-308 and its pluggable type checkers is all about strengthening the compiler so that it prevents more of the most frequent bugs like NullPointerExceptions. It allows us to make our code more expressive, to give the compiler more information about our intents so that we can prevent bugs from happening. Brilliant! Project Lombok also goes in that direction: it adds a couple of annotations and customizes the Java compiler in order to minimize the amount of boilerplate code we have to type. Once again, by doing so, it improves the expressiveness of the language, allowing us to say more things with less words, thus reducing the likeliness of ambiguities and errors. Awesome! Lombok and type checkers will definitely be part of a couple of projects too. The only thing that really made me uncomfortable with both of these presentations was this question: “Why the hell weren’t those techniques in Java 5 already?”
My fourth and last discovery was Pomodoro technique. Once again, heard of it before, but never dug into it. And then we had this guy with a strange Swedish accent in front of us, playing with dolls, showing us handwritten slides with simplistic drawings. And you could hear the disappointed reaction of a lot of people in the room: “sounds nice, but not applicable to me”. That was my first reaction too. Software development requires long slots of concentration because we need time to load the whole conceptual model of what we’re working on into our mind before being effective, and this implies some overhead. But then when someone asked this very question to the speaker, he answered something like “what if you are loading too much? what if limiting the amount of time you are going to spend on a given task forces you to load just the minimum you need to solve the matter at hand? what if it made you more productive?”. And it made me think: “hmmm… It’s worth a try.” So I will probably try that as well soon.
Overall, this edition of Devoxx was great! The first 2 days, I was somewhat afraid that it would be disappointing, because you could feel that everything was “cheaper”, that there were less sponsors, less schwag, less tempting hostesses. But then the most important part was preserved: amazing independent content and a great community spirit. Finally there was an interesting special guest this year: Twitter. Twitter was everywhere. People were tweeting live from the sessions, there was a projection board with all devoxx-related tweets in the hallway. I and a bunch of my colleagues were even using twitter to cover Devoxx live for our fellow Axenian java developers on our intranet. Twitter was really everywhere this year.
So thanks a lot to Axen for allowing me to go there. Thanks to Stephan and the BeJUG for putting it all together. Thanks to all the great speakers and to my colleagues. This was really a great edition and I can’t wait for the next one.
PS: All the talks will be available in the weeks to com on Parleys.com. So stay tuned.
Software Engineering Is NOT Dead!
There’s been a few reactions lately about the Tom DeMarco article. To be honnest with you, I didn’t know the guy but apparently he’s quite respected. And the reason why I didn’t know the guy might be related to the fact that he wrote a software-related book entitled “Controlling Software Projects: Management, Measurement and Estimation”. In other words, he’s the one (OK, one of the guys) responsible with all those project managers asking us for sharp estimates, negotiating them down with us, and committing on them without our agreement, leaving us with no choice but to produce crappy software and/or fail to meet the deadlines. For me, Tom DeMarco looks a lot like this Dr. Winston D. Royce dude, who first described the theory of Waterfall methodologies and forgot to write the following sentence in bold font: “the implementation described above is risky and invites failure“. No kidding!
My reaction is about the same to what DeMarco took 40 years to realize. Software Engineering is not dead, it has never lived! There has been a lot of controversy about that, some people arguing it’s more of an art, others saying it’s science, yet others that it’s more like craftsmanship. At the end of the day, the only fact that there is a controversy shows that it doesn’t fit in the hole we’re trying to stick it into. And yes, this blog is called Software Artist, but I have to tell you that it’s more as a reaction to those who are fiercely trying to “industrialize IT processes”. Oh man, that makes me angry! In the end, I have to say that the more I think about it, the more I like the idea of craftsmanship.
Because craftsmanship is all about finding the right balance between the techniques that you’ve learnt and the intuition that you have about what you’re doing. And finding this right balance requires a lot of practice. Note that I didn’t say “time”, I said “practice”. I like it also because for any craftsman, using the right tools for the job is fundamental, and once again, note that I said “the right tools”, not “the tools that everyone else is using in here” or “the tools we invested a lot of money on and we need to make up for”. And finally I like it because when a joiner tells you that he doesn’t know exactly when this wardrobe will be finished, you don’t bother him with that because the fact that it corresponds exactly to what you need, and the fact that it will last a very long time, largely makes up for this little uncertainty. And if he tells you he’s going to need another 4 days, you don’t negotiate, because if you know better how to do it faster, why in the world didn’t you do it yourself in the first place? Or why didn’t you go and buy one at IKEA?
Now after re-reading the above paragraphs, I realize that my statements might seem a little harsh and extremist (as usual). But I don’t want to sound negative here. So if you manage software people and you feel disturbed by this perspective to lose control, let me just tell you this. Software can be incredibly powerful, it can really create tremendous value in a very flexible way. And I’m not talking about allowing you to just save money. I’m talking about the possibility to develop your business and create value from scratch. But the more value you expect to create, the more you have to ask yourself whether you absolutely need to control every aspect of the software creation process. Remember, you’ve tried it before, and it most probably didn’t work as expected. But fortunately for you there’s a different approach. Empower your software team. Don’t lead them, but make their ride smoother. Don’t make them work FOR you, work WITH them. Don’t consider them as standard office workers. Instead, hire the best craftsmen you can find and trust them with your project. Make it theirs as well as yours. Surrender on this idea of controlling everything and you’ll be surprised at the result.
Software engineering is not dead, because it has never existed. Hence there is no need to mourn it. Let’s just roll up our sleeves because we have a few palaces to build for the years to come.
We don’t need an online IDE!
I’m on vacation this week, and it’s great. I usually try to take at least one week off in between missions because it’s the best time to do it. Nothing to worry anymore about the one before, no knowledge of the one ahead, my head is free to dream and wander around and I have plenty of time to move forward on personal projects.
Now beyond my work on betRway.com, I’ve been thinking a lot today about the idea of an online development environment. On my last project, I’ve seen a lot of the possibilities AND limitations of current RIA technology, and more specifically the most advanced one IMO, ie Flex. Combine that with some of the modularity offered by OSGi on the server-side, the productivity brought by things like Grails, and more importantly the promise of unification of all of those technologies under SpringSource’s sponsorship… and it’s starting to become more and more interesting.
So I googled “online IDE”, and I found this great article on DZone, which is a few months old but gives a lot of links to some of the services that are already offering both niche and generic online environments. I’ve browsed through all of these and I have a bad feeling of “déjà vu”. It’s like those mobile web sites that try to reproduce a trimmed down version of their web counterpart: it doesn’t really work, and worse, it doesn’t even use all the potential of mobile platforms. It’s like we’re trying to copy our desktop IDE onto the web.
But when you really think of it for a moment, the reason why we need version control systems for example, it’s because everyone is working on its own, and we need to synchronize at some point. But this constraint almost disappears if we’re all working online. And online development can have impacts of similar magnitude on things like continuous integration, deployment, monitoring. Some of these tasks don’t even make sense anymore. And how about several programmers working on the same artifact at the same time? And think about the computing power that could be available for code generation or compilation…
The way I see it, even the programming languages that we use today are not designed to work like that. Think of Java packages correlated with file system directories. Think of all these destructured text files that our IDE’s have to parse and index to make some sense out of them and allow us to navigate through them: what if text files are replaced by databases at some point?
I’m just thinking out loud here, but I’m wondering whether we shouldn’t forget about everything we know in terms of programming paradigms, and get back to the objective: producing working software collaboratively. What would be the best and simplest way to do that, knowing that we are starting to have all the tools we will need in order to move our workspace into the cloud?
As far as I’m concerned, I already know what I would like in such an environment:
- More graphical programming, especially for high-level design, because visualizing is still the most efficient way to create and design IMO.
- No more boilerplate tasks like “check out”, “check in”, “run tests” and things like that. Just “share my code in the public workspace” and “test on save”.
- The ultimate reproducible build environment: everyone is using the very same frameworks and libraries at any time. No more environment variables or shell idiosyncrasies.
- Smart client stuff, with offline mode, auto-synchronization and conflict resolution when back online.
- Methodology directly integrated into the environment, not some small window on the real thing. Issue tracking, user stories, all of that at your fingertips.
- Direct communication with your remote peers through advanced tools like whiteboard, webcam, code review.
In fact, we don’t need an online IDE, not in the sense we think of an IDE today on our desktops. We need more than that. We need a collaborative environment that uses the full potential of the cloud to help us produce better software more quickly.
What do you think? What kind of high-level functionality would you like to see in such an environment? How do you picture it?
Meta-Agility
I’ve been a professional software development consultant for 3 years now and I’ve seen agile methodologies become very popular in the company I work for. A lot of people have started using SCRUM on their customer projects and the approach has proven to be very successful. I think that the most surprising realization people have come to is that for years, if not decades, we’ve been stuck with the old way of doing it, thinking that software development could be planned and industrialized just like any manufacturing process. And a lot of software projects have failed, over and over again, before some people actually started to think outside of the box and came up with a more pragmatic and realistic approach.
Now, even though the methodologies themselves are very interesting, even though those methodologies still have plenty of room for improvement, I’m starting to see people trying to map agile methodologies on other things than just software development. People extract small chunks of SCRUM, like managing tasks through post-it notes, frequent synchronization meetings, specifying deliverables in user stories. But after playing a few months with these fun tools, they are starting to realize that they don’t work so well out of context. Because what makes SCRUM so powerful is the fact that it is a small but very consistent set of practices that all work together with common objectives to reach: the four principles of the Agile Manifesto. And it’s becoming obvious now that we cannot just take a few of these practices out of context and expect them to work for other purposes.
In fact, I have the feeling that people are more and more seduced by the meta-level of agility, the reflexion that led us to rethink our whole way of working to reach better results. And in my opinion, THIS is what we need to reproduce: the approach that led us to design the methodology, not the methodology itself.
Let’s try to analyze this generic approach:
First of all, let’s define our scope. For SCRUM, it was software projects with everyone working on the same spot at the same time. In Axen right now, it’s change management, more precisely how do we introduce a new business model into our company while keeping up the good work on the existing one.
Second, what’s wrong with our current way of working? For software projects it was that everything was linear (analysis, design, development, testing) and offered really poor visibility on how things were going. For our change management process, it’s the fact that all the team work is pretty much done in disconnected after-hour meetings, because everyone has a day job to keep the existing model running. The end result is that a lot of energy is wasted in pointless discussions and motivation is lost inbetween meetings, people working pretty much on their own.
To be more precise, agile methodology gurus have come up with a very interesting way to think of failures and solutions in a very constructive manner: what do we value over what? For change management, examples could be:
- remote collaboration over individual work and synchronization meetings
- small manageable objectives rather than big multi-year expectations everyone loses sight of
- professional evolution over personal sacrifices in exchange for fun
At least that’s my view of what’s not ticking in our current way of doing it. I know that other people have different views and hopefully we’ll soon have a debate and come up with a consensus on the four or five values we need to encourage for everything to work.
Then when you know the values you have to put forward in order to reach your objectives on any project in the same context, you can start to think of the tools and practices you need to implement:
- remote collaboration can be helped with collaboration software easing communication and issue tracking
- user stories are good for software, but the actor/action/goal paradigm might not be the most adapted to the implementation of new business practices. We have to be creative and find a new way to define our “requirements”.
- change management cannot be free, and investing money to free up time is not enough. Maybe some of this money needs to be dedicated to training participants on new techniques and knowledge that will improve their professional experience while developing the global expertise of the company.
And of course, once again, plenty of ideas can come up if we allow ourselves to think outside of the box and stop trying to make new stuff with spare parts from old stuff.
I will soon try to initiate this reflexion inside Axen and hopefully we’ll come of with a new change management methodology that embraces the constraints of this context rather than trying to hide them under the carpet. To be followed…
By the way, if you work for Axen, you know that the company takes great pride in involving consultants into its evolution. So what do you find motivating or not when working on those internal projects? If you don’t work for Axen then maybe you’ve worked on similar change management projects and you have your own experience on how to make it work while involving everyone in the process. I’m very interested in your feedback.
Goal-Driven Development
It’s always amazing to see how people find it hard to compromise, to nuance their opinions about things. And I’m probably the first one finding it hard. But when it comes to software practices, boy it’s annoying.
I was talking to a colleague of mine the other day, we were talking about unit testing and other best practices, and I boldly and shamelessly said to him: “I haven’t written any unit test on this project.” He stared at me with a bit of surprise, then with a bit of disappointment and finally with a bit of something like… disgust!
“What!? No tests, but why? How can you pretend to be a software architect if you don’t practice systematic unit testing?! Oh my god!…”
My first reaction was a furious urge to hit him in the face. But then I remembered myself a few years back, and I did nothing but leave him in his panic state and disappointment.
When I started working as a consultant, I had already written a few applications in engineering school, but strangely enough they didn’t really talked to us about software quality, agile methodologies and other modern best practices. We did formal programming, Prolog, we reprogrammed a memory management unit and wrote a compiler for a subset of the Java language, but nothing useful ;o).So when I discovered that some people were actually doing things in a rational way, to write better software, I was at the same time impressed and overwhelmed by all of that. Design patterns, continuous integration, test-driven development… I had never seen those in the real world, but I read a lot of books and websites and it seemed so nice that I came to think that it was the only way. And of course I was wrong.Fortunately, I started working on real-world projects, dealing with all sorts of external constraints. And no matter how hard I tried to impose “my” great software best practices, everybody looked at me like an alien because they just didn’t understand why I was talking about all this stuff. So when I was fed up with complaining about no one understanding what should be done, I realized that they were at least right to wonder. Why are things like TDD, CI or Design Patterns so important?
When you read so many articles explaining to you how to write unit tests, they all seem to assume that unit-testing is good in itself, as if it was some kind of axiom. But the truth is that no matter how good they are, writing them and maintaining them is a real pain, right? Lesson learned: when something is painful but good for you, there’s gotta be a better way. But a better way to what?
Because for me that’s the real problem: losing sight of the objective. Unit-testing and TDD are not good in themselves, they are just one best practice which allows you to improve the overall quality and robustness of your code. Why so? Because when you write your tests before the corresponding functional code, you considerably reduce the probability of a bug in the functional code. And robustness comes from the fact that whenever the implementation of a given functionality is modified over time, unit tests are there to ensure that the overall result will remain the same. Fine! But how about a better way?
First, let’s talk about reducing the probability of bugs. The main problem with code is that it’s written by us, human beings. And like it or not, we are faillible, we make mistakes, and the more we think we don’t, the more we actually do. Now rather than testing everything that we write, isn’t there a way to reduce the amount of code that we have to write? I can tell you that: there is a way!
I already see my colleague smiling if he reads this, because I’m so obsessive about this “way” that it becomes ridiculous. Take care, here comes the dirty words: code generation. Of course I’m not talking about the kind of code generation that just displaces the problem elsewhere, that is in diagrams that are the ont-to-one mapping of your code. I’m talking of a higher level of code generation, I’m talking of Model-Driven Architecture.
I know that many programmers don’t like it, have read many articles about and introductions to MDA without ever going further, mostly because programmers like to… program, not draw. And I can understand that. And if you’re in that situation, then you’re stuck with test-driven development… or any other “way” you can find. But if you like to have a better view of the big picture, if you want to accelerate your development and increase the robustness and quality of your code, then have a look at this (my favourite), this and this. You might be surprised.
Will it completely replace unit tests? I don’t think so, but it can create a situation in which you have so dramatically reduced the amount of code to test, that it can be interesting to wonder whether it’s still worth the effort.
My main point is, software best practices are nothing without the goal they allow you to reach, and forgetting that is the best way to stop looking for better ways, to stop innovation and progress.
The Testing Dogma
When I was in college, we had a very talented physics professor coming directly from Scotland. And as I was in a French engineering school, I was more used to the French way of teaching science, with a lot of theories, demonstrations and proofs. So when I first saw this guy with all his experiments and observations, I thought the man was crazy but in the end, a fact was a fact, and I didn’t really care about why a specific equation applied. I just needed to be convinced it was true… until someone proves us wrong. That’s what science is all about.
Yet, some French scientists tend to be distrustful with the whole empirical stuff, probably because they can’t help thinking that it’s not because you observe something a 999 times that it’s going to repeat itself a thousandth. So the best alternative we have is to prove it by theory, using mathematics and a lot of tools like theorems, matrices, integrals, etc., even though it’s far more difficult. And once it’s proven with theory, we can more or less take it for granted (provided our reasoning is valid).
Now what if I want to assert something about a piece of software? I can either create an experiment to show that it repeats itself: that’s a unit test! Or we can prove it theoretically using mathematics… Yes, there are formal languages that allow you to prove your programs. They’re very complex to use but hey, reliability has a price!
Fortunately for us, the metaphor stops where the specificity of our case begins, because with software, we have a third option. I won’t say the dirty word right now because I know you’ll run away. Let’s just consider that there are basically three types of testable code:
- code that is very simple to write but you’re testing it because you want to make sure that no one can break it with a wrong copy-paste or something like that
- business code which is a bit more complex, for which you have to write equally complex test code, with the risk of having correct code tested by wrong test
- all the rest, which in my experience is not as much as we think usually.
Based on my experience, I would tend to do the following:
- I write regular unit tests for ALL the rest.
- I don’t test complex business code, I do code review on it.
- For simple code, I shouldn’t even have to write it in the first place. If it’s so simple, then it can certainly be generated automatically by a generator I trust (that’s it! I said it!)
What’s your position really? Set aside the “testing-is-good vs. not-testing-is-bad” dichotomy, what would be your testing strategy? Do you use code generators to avoid testing boilerplate code?
The Fourth Commitment
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?
First you’ve got Agile…
…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.
The Third Commitment
Let’s say you’re an Agile guy. You are pragmatic, and you perfectly understand the importance of added-value-driven development. You hate Big Design Up Front even more than his big brother “Big Requirements Up Front”. Why? Because it assumes that your customer knows exactly what he wants, and will never change his mind. And you know that it is ALWAYS wrong to assume that.
But let’s say you’re a contractor too, and at some point, before even starting to work, you need a contract. And where there is a contract, there are commitments.
Usually, the first one that comes into play is budget. That’s the big thing in the business world: customers want to have full control over their costs, and as long as your product is not online, your project is nothing but cost to them. Then of course, you can’t commit on budget when you don’t know what you will be asked to do for that budget. Or your customer has a strong time constraint, and tells you that your product has to be ready for such date. And that’s when excellent commercial skills start to become handy: budget, time and scope, those are three very difficult commitments to combine… and negotiate.
The problem is that if you’re just a good commercial guy, you end up committing on all of them because the customer is king, right? WRONG! Because you’re an Agile guy!
Imagine your contract as a bucket, and each commitment is some amount of water. If you start pouring budget and time in your bucket, then unless you’re very good at estimating technical constraints for a given functional scope, your bucket is very likely to overflow with scope water. And even though you know exactly what amount of functionality you can still pour into that bucket, it’s very likely that you will lose the market because other contractors won’t be as “good” as you are. And it’s the same with budget and scope first. Even if you’re good enough to estimate exactly how much time it will take, your customer is likely to be disappointed and to choose another contractor, who promises to do it in less time (even if he’s less realistic than you are). And it’s even more difficult when time and budget are strongly dependent on one another.
I heard someone in the back of the room: “And what about scope and time first?” Come on! Do you know many customers who can tell you “OK, we want to achieve that goal during that time, and we don’t yet about budget.” Well, there are such customers, there are such situations, but that’s more typical of a non-fixed price project. OK, so let’s say that you want to do fixed-price.
I guess the problem at that point is that there is always too much water for this small bucket, because of competition and because the customer doesn’t understand a thing about what you’re doing.
So, what’s the solution then? What’s the Agile Solution? Let’s quote the Great Martin Fowler, in his famous article about Agile Methodologies:
This doesn’t mean that you can’t fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.
What does “controlled manner” mean? In other words, what third commitment can you use to just fill the bucket without losing the market?
Well, I would say it depends on your customer but I see at least two leads…
