The merge that breaks it all

Don’t know about you, but one of the things that truly breaks my ba**… err, nerves is when a team member commits something that breaks the application, so when you merge and run, all hell breaks loose.

Sometimes the application does not even compile. That’s negligence, and it surely isn’t nice to handle. But at least one usually ends up fixing this quite fast.

And sometimes the application compiles but does not “behave” anymore: that REST service is returning a 500 code, that Hibernate mapping throws an error, etc. Then you begin spending time, a LOT of time, fixing whatever mess your colleague has made.

And all this because your colleague committed half-finished code. In other words he didn’t bother to TEST what he implemented!

You’ve got some nerves!

(there goes the monologue)

Okay, so just in case you didn’t notice, we’re working in a team. And you committing unchecked code repeatedly just broke something. It broke the trust we had in you.

And we seriously need to trust you. The team is required to deliver within reasonable delays. We try our best to evaluate the time we needed to deliver. We try our best to maintain what work we have delivered so far so that the client does not end up with bugs on features that were working a week ago. We try our best. We try to be professionals.

But if the application breaks down regularly because of you then our team will start… not-liking you, really. That will bring down the team’s morale and delay any other work we were supposed to finish. That will bring down our collective effort to keep this application stable and to the highest quality standards possible.

Seriously, if you commit unverified (dare I say it: untested) work to the repository it can only mean one of three things.

You don’t care!

Maybe you’re not enjoying your work as much as you hoped. Maybe the guys above forced your hand into accepting that “team lead” position, or that “functional analyst” role you’re not really interested into. So your morale is undermined and you stopped caring about the code.

Maybe you don’t think your team is worth putting in your time and energy, who cares if the code works. The project being developed is bound to fail anyway. I mean, whatever man.

Or maybe you want to do the things your way, even if it annoys the rest of your team. They don’t understand how clever you are.

Well there’s nothing we can do about that. If you’ve decided that’s your line of work, so be it. But trust me on that one: your team won’t shed a tear if you leave the project. That’s as much return as you’ll get.

But maybe that’s not it: we totally misunderstood you! The real reason is that…

You don’t know the rules!

Of course! That must be it! Nobody told you about the “rules” when working in a team!

Oh boy, there’s a lot to learn. One of my main teachers on this topic is Robert C. Martin, if only for these two bits of advice from his book “The Clean Coder“:

  • “Do no harm”: in other words, make sure you don’t introduce bugs. If you commit code that breaks the application… well you obviously introduced a bug or two!
  • Respect the “boy scout rule” : “Always check in a module cleaner than when you checked it out.“. In other words don’t check in messy stuff and clean after yourself.

Check Kent Beck, read Martin Fowler, browse through some of DZone’s links about teams and teams’ good practices.

These guys have experience about working on projects! And they share it! More often than not their posts are about the inner workings of a development team or the dynamics of the development process. You might not learn about the latest version of <<enter favorite framework here>>, but you will learn a lot on good practices and how to work together.

So there, maybe you simply need to learn how to work together.

But wait… wait I second… Oh I get it! I GET IT!

You are testing US!

You want to check whether our ingeniously-introduced bugs will be detected by OUR tests! What a better way to see if our code is sufficiently covered? Heck, you are incarnating our human Mutation Tester!

That is brilliant! Bravo!

Of course, we are somewhat responsible to ensure that a red light goes off should anyone make a mistake. We’re human after all!

Of course it would be way more helpful for us if you actually helped us with our coding by, oh I don’t know, sitting with us and pointing our flaws (politely, please. No one likes being laughed at). That’s the whole pair programming / mentoring thing they talk about.

But then again, who am I to argue with you?

Seriously though

Evolving and adapting is tough. As developers we are constantly required to evolve technically: we use new frameworks, try new libraries, learn new programming paradigms. But the evolution is also organisational, behavioral: that Agile thing has grown up from a necessity to adapt to new requirements in the IT domain.

Gone are the days when you’d work alone and kept the knowledge to yourself. Nowadays we develop by communicating with each other, by talking with the customers, by delivering working software as soon as possible and by making our code so well though that we’ll be able to change it at the customer’s request.

And we don’t commit broken code because we respect our team mates, don’t we?

Cheers!

Leave a Reply

Your email address will not be published. Required fields are marked *