Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

It's all about fun...

Friday, September 08, 2006 Pablo Santos 1 Comments

It's been already nine months since we adopted scrum as our way of working. Nine months in which our software has passed from just a design (we spent several years planning before finally getting the capital to start) and some code to an almost finished product (we are finishing the last details, creating a first official release, although there are already some companies using it in beta status).

Sometimes you only see problems all around, but I see this happens in any project. But when we look behind we see we have managed to reach this close-to-production status: what are the things which helped us during our way? I would bet they were: agile methods (scrum), team spirit and having (some/lots of) fun (the last two being quite related). And if I have to make it simpler I would say: people, fun, competition.

I already had the chance to decide about the software process to adopt in my previous company, but this was the first time I had to take (shared with David) full responsability.

First time I heard about agile methods I have to admit I was very exceptical. It sounded to me like destroying all the hard-gained methodologies which I had studied back at college. Even I thougth it was promoting untrained people to do programming... I was deeply wrong. In fact, now it looks exactly the opposite to me.
Old-rigid-boring software engineering methods (or methodologies if you prefer) try to focus on the way things have to be done, instead of people. Those methods really push to have interchangeable software developers, managed by non-software people, replaced as if they were mechanical pieces... Precission, what they claim is lacking from nowadays software development, is the saint grail to look for. If you fail... just try a little harder, maybe some documentation was missing, maybe you didn't write some diagrams, maybe you didn't use the right case tools(they don't call them case anymore... wonder why?). They would never (well, almost never... :-P) ask whether people need a salary raise or a quiet environment. Stronger, harder, more precisse working... That's all.

And, at college, I believed that. Well, maybe I had some small doubts because I always liked programming, I've seen it as the cornerstone of software engineering, so the classic approach didn't fit perfectly on my mind.

It was only some time after when I first found code complete (first edition) and started noticing that there were well-known people having a different approach. (I wish I had found this book earlier).

Later, learning about extreme programming, rapid software development and so on, I realized that I was wrong about agile. Agile methods are all about people, about having good people. These methods don't enforce people interchangeability, something I find great.

We all spend a big amount of time at work (I won't look at the numbers... :-) ), so it is great if we can enjoy it. Yes, it can sound strange but think about it: maybe hundreds of years ago there were not so many jobs you could enjoy, but today if you are lucky enough to be working on something you like... why shouldn't you enjoy it?

Before starting this project I re-read Peopleware, and there were a couple of things I tried to keep in mind: set up the right environment for the people, and don't try to artificially create a team. So, creating a good working place was the first thing we tried.

Then there is the issue of making teams jell as Peopleware states... At the beginning we didn't know how to achieve it (nor we do today, it just happens... or doesn't). Is very easy to call a group of people a team, but a team is much more than a bunch of people sitting together. Now I think we are really working as a team, we share a same goal, and we are all really motivated (hope not to break it writing about...) and... to be honest, I still don't know how to achieve it. I guess that things like flexible timetable (people can arrange their time as they want, and they can feel free about arriving late or leaving earlier) can help (well, in fact I think we have a problem: workaholism, so we will try to force ourselves to leave at six, finally!).

But in my opinion there is something else to make (and keep) a team: the competition. When you feel you are racing against someone else: you try to push harder, to go higher, to make it better. Ok, maybe it depends on the project you are working on, but I bet you can always create the illusion.

In our case we all share the feeling of being making a world class product. Whether it is real or we are just dreamers only time (and market) will tell. Anyway, having a look at what others are doing in your field, and pushing harder to improve, seems to be a great incentive for people, and helps creating a common target, and then a team.

Well, I still have to write about what we did wrong... :-P
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.

1 comment:

  1. I'm really sure most important side of software development is people and how they're interacting.
    We used to belive that well stablished processes could achieve great results working with dummies or newbies, but we were absolutely wrong.
    Our experience with Scrum (like with others agile methods) said us it is just a wrapper of this people-centric filosophy: good people working as a team, with full responsability and right environment where you feel you're making something great.