My first commit in my project resulted in the nightly build being broken and people are all over me as we are nearing the release. I want to send an apology email that should sound sincere and at the same time hinting that this was my first commit and this would not be repeated any more.
Being a non-native English speaker, I have difficulties coming up with correct words. Can someone please help?
Don't apologize!
Also, I bet your team fails the 'Joel Test' and can't make a build in one step.
If so, this would be another thing that you shouldn't apologize for. Indeed, it's a team anti-pattern.
Bagels. Donuts. Etc. At one company I worked for in the past, checking in broken code or otherwise causing colleague disruption is generally resolved by the bringing in of apology foodstuffs the next day.
We had a guy blow away a production database one day, causing massive panic and a late night for the whole team. The next day he grilled burgers for lunch.
I love co-worker apologies. Tasty, tasty apologies.
Two quotes for you:
The man who makes no mistakes does not usually make anything.--William Connor Magee
Anyone who doesn't make mistakes isn't trying hard enough.--Wess Roberts
I agree with Jim G., don't apologise but do learn from it and don't make the same mistake again... keep it DRY ;)
Don't apologize, just FIX IT as soon as possible. It is okay though, everybody breaks the build at least once, in my last company it was something of an initiation ritual. When a team member broke the build we would put a rubber duckie on his desk in the morning before he came in, this let him know he broke the build and he would fix it.
We called it the Continuous Integration Duckie and when you had it for the day people would tease you but it was all in fun, none of it was supposed to be mean spirited.
We took something like a broken build and turned it into a team building exercise.
"Sorry! My bad!" is how I usually apologize when I've broken the build. It happens. But as others have said, this is an opportunity to improve your systems so that one person cannot so easily break the build for everyone else.
I would not make a formal apology in these circumstances, but if you actually feel that a more formal apology is appropriate, then your apology should do these things:
That is, "I'm sorry [EXPRESS REGRET] that I inconvenienced you [TAKE RESPONSIBILITY] by accidentally [SAVE FACE] breaking the build [STATE THE PROBLEM]. Doughnuts are on me tomorrow. [MAKE AMENDS]"
Each part is necessary in a proper apology; if you don't state the problem then it is unclear. If you don't express regret, take responsibility, and make amends, then people feel like you're insincere. The face-saving part is the most overlooked part of an apology; the face-saving part is what reminds the injured party that you are a valuable coworker who sometimes makes mistakes, and not an idiot (or a saboteur!)
Finally, some thoughts on build breaking:
I work on the C#/Visual Basic compiler team. Of course today Visual Studio is now such a massive project that it has a team of its own just to manage build infrastructure, and a huge room with its own dedicated air conditioning system. Back in the mid 1990s when I started as an intern the Visual Basic build team was one intern -- me -- and a closet full of machines. Times have changed!
Back in those days before continuous integration and strong checkin processes, teams would have a variety of penalties for breaking the build. On some teams the penalty was that if you broke the build, you had to wear a funny hat every day at work until someone else broke the build. On some teams, if you were wearing that hat you were responsible for verifying that the nightly build was correct.
That last bit sounds maybe cruel, but it actually served a valuable purpose. Since almost everyone broke the build at one time or another, eventually the entire team would learn the processes for verifying the nightly build.
Don't apologize. It's your coworkers who are to blame for not reviewing your first commit and not having a quick feedback system for builds like a continuous integration server.
At my current job we have an informal rule that someone who sneakily commits just before leaving work and turns out to break the build has to bring candies/cakes/drinks for the whole team the next day. But we do have continuous integration that warns us of a broken build during the day. And the rule probably wouldn't apply to someone's first commit.
Anyway, a formal mail of apology is probably a bit too much.
A fundamental rule - when you're wrong, ADMIT IT :-| You don't have to grovel in apologies. Everyone makes mistakes. The pros admit it. That's teamwork. The other team members should be pulling together to help you over it. If they don't, ASK for help. The most that has to be said afterward is - what can we learn from it?
They say a successful marriage is based on three little words - "I was wrong".
If someone doesn't make an occasional mistake, they're not working, but a mistake one doesn't learn from is two mistakes.
If your company already has a way to test your build changes, then (A) your changes either failed (but you checked them in anyway) or (B) they succeeded (and you need to build a new test case).
If your colleagues gingerly test their changes and expect to find breaks on the nightly build, then (C) you have a brittle process (and you need to introduce testing like that found in Extreme Programming).
It is possible that (D) Your changes caused unforeseen changes in Bill's code that were either in place before or changed on the same build as yours.
Depending on how you and your company test, I would apologize on a case-by-case basis:
I'm sure there's an (E) that I haven't thought of.
Notice that I am saying "to reduce the chance of re-occurrence" rather than "so it won't happen again." It will happen again. But you may improve your process to reduce that possibility. That, I think, is one of the marks of a winning programmer.
Don't apologize. You are human and you will make mistakes. Everyone will break the build occasionally, the key is to just fix it quickly.
As for the people jumping all over you...well I'm curious as to if they've ever written in a bug.
How to approach this depends on the atmosphere in your group. If it's a blame culture, I'd be very careful about apologising and how you do it. If it's a collaborative, positive atmosphere, then yeah, something along the lines of "I messed up, I'm sorry. How can we avoid this in the future?" is probably a good idea.
In any case, a goof up like this should be accompanied by some sort of post-mortem to a) find out how it happened and b) how to minimise chances of it happening again.
I'm not familiar with your structure (I work in a very different environment) but ultimately, the reality is that occasionally, people make mistakes, and things get broken. You learn from the experience and move on.
In my environment if you broke the build you would get a good natured ribbing and some witty cometary. I'm not sure which English speaking country your in, but it could be that as a non native English speaker you are not getting the underlining nature of the comments.
Being from the other side as a Senior developer I once commented on a code review that some way of doing x "sucked" not because the code was bad but do to the structure of the project. It was more commentary to myself that I need to fix the structural problem. Only later did I discover that the Jr Dev though I was very angry at him due to my inaccurate flippant speech.
Um. You get the broken build token. Pass the rabies on to the next lucky recipient. Happens all the time. Quality is important, but mistakes are inevitable. Fix them. Move on. Shame the next poor bloke.
The TEAM failed.
Your company needs more code review on a dev doing a first time build.
I just don't see how a team allows this to go on without them doing a review and offering some assurances along the way that you are doing things correctly.
Being close to release time is not an excuse, but a better reason to double-check new code.
If your release cannot be easily undone, there are even bigger problems with this group.
As a general rule, I would say:
If your checkin causes a compiler error you would have caught yourself had you done a "get latest" before checking in, a simple "whoops, my bad" is in order. (especially if you stroll in at 10 the next morning, while everyone is deciding which changeset to roll back to)
If your checkin causes general unexpected behavior, even runtime errors, I don't think it should be held against you. It comes with the territory. As long as everyone's "get latest" generally gets passed their compilers, people really should not be throwing a fit (with a couple exceptions like deleting a database, deleting the server copy of the project and all the changesets, or anything else that is so dumb that people have to assume malicious intent).
Better a late answer than never...
As many others have said, don't apologize for breaking the build. Simply admit that it was you and get on with the job. This stuff would happen whether you were there or not, and nobody deserves to be treated poorly because of it. People react badly under pressure, so if you are able to remain calm and simply get on with the job, you'll stand out when it matters. My advice for when people give you a hard time is to simply avoid being defensive, defuse the situation by letting people know you are either on to the problem or you are quick to seek advice if you find you've become stuck.
Personally, I see a broken build as an opportunity.
So what I'm saying is that breaking the build occasionally means that people are doing their jobs. Sure you might have made a mistake, but if you use it as an opportunity to learn, you are doing your job simply by learning to do it better next time.
I don't understand why people are all over you. If the system is setup well, they should be able to tease out your changes / fix them very quickly.
But again, if you are one of those guys who broke windows build, Then ... I can't help. (It is incredibly hard to do btw - before anyone questions MS build philosophies, but now and then someone does it - and the whole company QA stops for a day).
And yeah - don't apologize. Just have a chat with your manager and make him understand that you learnt from what you have done.
Builds break all the time. Bugs and mistakes are a fact of life, and that's why you should have a process that minimizes effects of bugs and mistakes.
If a build breaking is that big a deal, it means your process is broken.
You should be doing continuous builds, not nightly builds.
Tell them they need CI builds per check-in. That way you wouldn't have to wait until the nightly to know it's broken. YEA!!! Tell them it is the process that is wrong, nothing else. You just identified a gap in their system.
But yea, make sure to fix it. Not a big deal. It is not in production. Just a worthless nightly.
I would not apologise.
I would blame CI lead for allowing me commit broken build.
There should be a CI process in place for stopping developers from committing broken code.
If local build fails, then it should not be allowed to enter build server.
While I think some kind of apology can be in place, please don't say: "I will make sure this doesn't happen again." Because it will. And if it does it will bite you.
If you are working on an open source project,
just say "Sorry, I broke the build. May be I was too sleepy!"
and add it as a github comment.
It is because many open source developers write code during midnight.
A usual practice in my company is:
My company also has a nice way of handling such an "incident":
