Agility

Agile methodologies, especially SCRUM

Top 7 Reasons Why You Should Work for a Startup (clickbait intended)

It’s been a while since I’ve posted something here but as they say, desperate times… So as you might not know a lot has happened in my professional life since I wrote here. Last time I was getting ready to start a new job for Instaply, a startup based in the US but with an awesome team spread around the world. I worked one year with them, and then I was invited to be a coach for NEST’up Spring 2015. Then last month, I started a new job for another startup, based out of Brussels this time, called Take Eat Easy.

Just to get it out of the way, since the topic of this blog post is going to be about the advantages to join a startup, let me come back to the reasons why I left Instaply after just one year. It has nothing to do with the startup environment itself, and everything to do with the reason why I chose to go freelance in the first place: I love to choose the projects I work for and the people I work with. When one or the other becomes something I have to accomodate instead of something I fully enjoy, AND once I have tried everything in my power to make things go back to where they were at the beginning without success, I start listening for interesting new opportunities. That is exactly what happened here. I would have loved to keep working with those great developers. I didn’t believe enough in the project anymore to fully enjoy working on it. I tried everything I could to steer it back to where I would have believed 100% in it. I was not the only person to decide of course. I was offered a coaching position for a renowned startup accelerator I co-created, I moved on. The funny thing is that the first season of this same accelerator, 3 years ago, saw the birth of another startup: Take Eat Easy, yes, the same where I work now. Small world, right?

Now that we’ve got that out of the way, let’s get back to the present time now. When I joined Take Eat Easy, I made it clear that I didn’t just want to code, I wanted to have a greater impact on shaping the future of a business I really believed in: helping people eat better from the comfort of their home. So I joined as a VP of Engineering. If you want to know the difference with the role of CTO, you should read this article. So now I have the opportunity to keep building some software, but also to build a team with the best possible methodology and structure for the years to come. As a team builder, one of my main responsibilities is to grow the team, to recruit great developers. And that’s what brings me back to my blog.

Right now, we are looking for 3 key persons:

  • one or two Java backend developers to keep building our core system and make it stronger as we release our platform in multiple countries
  • one or two web frontend developers, familiar with Java (JSP, Spring MVC, etc.) but also very strong with HTML5, CSS and Javascript, to make our customer website and our internal tools completely ergonomic
  • one or two Android developers to bootstrap the development of our brand new mobile app, and help us with the development of our apps for restaurant managers and bike couriers, among other things

And I’m not gonna lie: I was expecting to get more applications. The fact is that we are looking for senior developers because we don’t have time to train newbies for now (sorry guys), and we need strong developers with enough autonomy and creativity to take matters into their own hands and really build the backbone of a great team. But still, I can’t help but wonder why we don’t get more applications.

First hypothesis: people just don’t know we’re hiring. Well at least now, you know (and your best developer friends will soon know, right?). I also published a few messages on targeted LinkedIn groups, there was a lot of press surrounding our recent funding round, and we do have our recruitment website where you can see our awesome industrial office space. But maybe it’s not enough.

Second hypothesis: the technologies we are working with are so commonplace in big corporations and institutions like the European Commission, that offer good paychecks and a comfortable 9-to-5 job, that developers are just too comfortable there to get interested in anything else. But I’ve been there, I’ve done that, and I know that working for those big institutions can look like a golden jail and eat your soul from the inside out.

Third hypothesis: startups are so rare in Belgium, that few developers actually know what it’s like to work for one, they don’t see all the benefits, and it sometimes looks too good to be true. So let me set the record straight and give you my top reasons why developing for a startup is so awesome (and of course, even more so for Take Eat Easy :oP )

Have an impact

More often than not, when I’ve worked for big companies, I never met the end users of the apps I worked on. Sometimes, the software I wrote never got to a real end user because the project was just dropped before the end (which tends to happen when a full waterfall development cycle takes a few years to complete before you realize your software is already out-of-phase with your market).

In a startup, not only can you see your final users, but you can meet them, touch them, feel their pain, and more importantly feel the joy and happiness that your software brings to their lives. When was the last time you could say that from the invoice checking ERP/SOA system your worked on (real world example)?

Learn some startup skills

I know so many developers who stay in their 9-to-5 job in a big company and save money for the big day when they will finally take the plunge and turn one of their million-dollar side project idea into a real business. I used to be one of those.

What if you actually learned some useful things while saving for your big coming out? What if you actually witnessed first hand what it takes to be in a startup rollercoaster before you build your own? What if you used this experience to see if you are actually CEO material, and in the process, put your full power to good use by helping a business you actually believe in? There actually is a middle ground between a boring dull job for a pharma company and creating your own startup: it’s called an exciting job for an existing and thriving startup.

Bonus: where are you more likely to meet your potential future cofounders, team mates and investors, at the European Commission or at the heart of the startup ecosystem?

NB: if you are already further down the line and you are planning to launch your own startup within a year, this doesn’t apply. Working for a startup is a long-term commitment and you will only benefit fully from it (and let’s face it, the startup will only benefit from your expertise) if you stay long enough.

Zero-bullshit

9-to-5 jobs are called that for a reason: so long as you clock in at 9 and clock out at 5, you’re good, no matter what you have really done in-between. If you do less than that, you can already feel the warm breath of your manager in your neck (and probably smell his bad armpits with this weather). And those companies are so much about appearance, that you have to disguise as a serious person, with suits and everything. And you have to attend meetings, watch boring Powerpoint presentations, play political games, and the list goes on forever.

Nothing like that in a startup, really. It’s pretty much like McDonald’s. Come as you are. Geeky t-shirts, flip flops, 3-day beard, whatever. So long as you do your job, you get results and produce awesome software, we don’t care how you look or when you come to the office. As a matter of fact, we know you are going to stay late, because you will love your job and your team mates so much that we will have to send you home! And no bullshit meetings or layers and layers of management. We are not here to justify our paycheck, we are here to get some shit done, and make the world a better place, one distributed database at a time (Silicon Valley pun intended). Anyway, you get my point.

It’s an investment

Whatever you do for a big company, where is the incentive to do your job better today than yesterday? But who am I kidding, if you are reading this your are probably such a perfectionist professional that you don’t need any incentive. But what about your colleagues?

In a funded startup, not only is the paycheck completely comparable to your current corporate one and probably even better, but you get one thing the big guys will never be able to offer you: stock options baby! I know, this is not a salary, and I am the first one to say it should not be bargained as one. It is merely a bonus. Some would even say it’s a gamble, and in some sense it is. But what do you call a bet in which you can influence the odds of successful outcome with your hard work, sweat and creative ideas? I call that a pretty good bet, one that won’t make you rich for sure, but might go a long way in setting you up for your own startup some day… or anything else for that matter. How about that?

Awesome colleagues

How many times have you complained about all those guys around you, who are not all bad, but have become so infatuated by such comfortable working conditions, that they have completely stopped questioning the status quo and the misery of their conditions. But you are stronger than that, right? You are still too young for that shit, huh?

Then how about working for a company that doesn’t settle for the average Joe Does-the-Job, but strives to only work with the most creative, no-bullshit software builders it can find? How about being part of a great team, and even participating in building it with all the great developers you have met throughout the years, and thus influence your stock options value even more?

Cool perks

Do you remember the last time you yelled at your computer because you still don’t understand why you get to build complex user interfaces and innovative backend systems on the same gear as Julie from accounting? And that chair, boy that annoying old chair that was probably already used by card punchers if you know what I mean, and has likely squeaked though Y2K bug times. And don’t get me started on those unbearable cubicles and that awful stuff they call food at the Sodexo joint downstairs (confess to me: when people ask you how it is, you still answer “it’s fine!” with an awkward smile). I’m barely exaggerating, admit it.

Of course, a startup is so much better on all those fronts. I needed a big 27-inch screen to do my iOS storyboarding wizardry properly, I got the green light for one in a couple of days, and now it’s proudly sitting on my desk. Inspiring creative work environment? CHECK! Awesome food delivered straight from the most trendy restaurants in Brussels? What else? (ok, the Take Eat Easy factor might help there). All those little thing that make you smile your way to work, along with Magic Assembly breaks, no-nonsense days-off policies, do you really need me to go on?

The (real) Agile way

I’m not talking about post-it fakery here. No “of course we do Agile! RUP is agile, right?”. Ever heard of ScrumFall? Remember those post-it notes that you ordered to migrate your project to Kanban, and that ended up arming your post-it war with your cellmates across the road, out of despair?

In a startup, Agile is not something you do to shake up your manager’s certainty, or to make your life as a developer less miserable in an Excel-driven management world. It’s a necessity. It’s the norm. It is what you do because it’s just the most efficient way to get shit done and to ship actual software out the freaking door and into the hands of your feedback-blowing users. Real Kanban with regular retrospectives with which you can customize the process to fit your team’s way of working in full collaboration (not against) a business that actually craves for your every line of juicy code.

 

That’s what a startup really looks like. And of course that’s what OUR startup really looks like, and will do even more so if you loved every advantage listed above and want to make them even more real by joining us.

Of course, I can already hear some of you in the back whisper: “oh, but that’s not all rosy, you will probably do crazy hours, and you will have a lot of responsibilities, and it might not work out in the end, it’s not safe out there, it’s a cutthroat jungle, and investors will make a lot more money than you, and your kids will see your sorry face a lot less, and yes, you will learn, but you will fail a lot to get there, and…”

I won’t deny. That’s all I have to say: I won’t deny any of that. I’ll just let you read it back out loud and leave you with that and my direct email address: sebastien.arbogast@takeeateasy.be

By Sébastien, ago

Change is Happening, my Friends!

Archaeopteryx_2I 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…

By Sébastien, ago

My Discoveries of the Year

logoEvery 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.

kanbanMy 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?”

pomodoroMy 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.

By Sébastien, ago

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.

By Sébastien, ago

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?

By Sébastien, ago

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.

    By Sébastien, ago

    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.

    By Sébastien, ago

    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?

    By Sébastien, ago

    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?

    By Sébastien, ago

    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.

    By Sébastien, ago