Overtime Blues - Part 1

The next subject that I want to talk about, and it's a large subject and quite dear to everybody's heart... working overtime. I might not get to all the points that I want to cover so it might span out to a few ranting blogs. Why do we do it? Work commitments? Getting ahead in the company? Caring about something and seeing it through until the end? Monetary compensation? Managers making you feel obligated to be a 'team' player? But is it worth it? I say no. I always like to escape my entire argument by saying that doing some overtime here or there is sometimes needed and necessary. But in most cases I say no. Let’s examine some of the common reasons why someone would have to do overtime. Poor/No planning. Unrealistic business/marketing commitments. Manager's over-commitment (poor planning). Scope creep. All of these are, for the most part are out of your control, as a dev. I still find it extremely tragic that as developers I see people unable to breakdown their own tasks and estimate them with a reasonable amount of reliability. And what's even more tragic is a manager trying to make time estimates without even consulting a technical person. And if it is with a technical person, it's with the WRONG technical person. Time estimates in my opinion is an art form, some companies out there have tried to quantify this process, a great article about this was written by Joel on Software. But back to the subject, overtime. In this day and age as developers we for the most part are held accountable for other people’s project decisions. The process of project decision making is 3-5 iterations outside of our scope, prior to us getting involved. And I say that's terrible. And what do we do about? Absolutely nothing. Doesn't that make you angry? Is your manager held accountable for his/her decisions or is it you that has to put in the overtime? Does the sales guy promise x,y,z prior to contacting you if this is even achievable within the timeframe? Why do they do this? Because they can... What we have to realize is that if you give in, it only perpetuates more of this type of behaviour. You have to break the cycle somehow. There has to be push back! Trust me, when there is push back from below to above, you're going to be invited to more 'decision' meetings, and self reflection meetings. Stand your ground, these are just smoke and mirror meetings where someone is trying to define what you're trying to do. And truthfully flat out tell them that there has to be a sharing of accountability on project commitments.

Tell me more thoughts on the subject? As for the post, more to come this week ;-)

Staying Still

A great question that everybody off-hand says is, "what if money wasn't an issue, what would you do?" And the obvious answer would be, "whatever I damn well please". Well what would that be? When I first started my career, getting out of university, I entered the work force during a downturn. Software jobs were few and far between especially for new grads, but I was luck, I found something interesting within the first month of graduating. In a year however the startup company which I was working for wasn't able to support itself and I found myself back at square one. I think the next 9 months was possibly one of the best times in my life. I was unemployed, I had a bit of money but I was still learning. Possibly learning more about life than I've ever done within the other two decades that I existed. And this is what made it so special. Going back to software development, there are people that are veterans in the field, working in software for 15-20 years. But you have to ask yourself did you do 5 years of work and just repeat those 5 years 3-4 times? or did you really work for 15-20 years? There is a difference between getting by and really thriving. My personality is if I stay still for too long I become indifferent, I lose my passion for the thing that I'm doing. And for most people that's OK. But I say no. Don't do that. Constantly always keep active, keep learning. Keep checking yourself, are you stagnating? Fight against staying still. You'll enjoy everything much much more, even if you had all the money in the world.

Alternative Realities

I always ‘believed’ in alternative realities, where every choice you make ripples into an infinite number of possibilities and each reality describes a possibility. Far fetched?…yes. But the beauty of the human mind is that we have the cognitive ability to partially predict what might happen based upon past and present events - so we can play out these scenarios within our own reality.

Today we’re exploring two stories, same players, same events leading up to the incident, and extremely different outcomes. In the first story, a team sets out on a new software project, call it project X, for a new client. They perform time estimates, get approval from all interested parties, do the design and start the implementation. Bam! A major roadblock hits the team. The manager asks the team to buckle down, absorb the roadblock. Due to the loyalty of the team, they oblige, put in significant overtime and solve what needs to be solved and continue on their merry way. The roadblock pushes there timelines down a month but being great dev. they push forward ‘hoping’ that everything will be OK. They deliver the software to the client a month late, boggled with failures. Ultimately they’re unhappy, unsatisfied with the work and it takes an additional 3 months to stabilize. The second reality, the manager identifies that there is a major roadblock, informs the client and together they formulate a plan on working it out. The team does as little overtime as possible, they get there best guys on the roadblock, they reduce scope by a few features and they deliver 2 months late. The client ultimately happy with the quality of the software and believes that it was a success aside from the late delivery. So what went wrong in the first reality? It’s really about setting expectation in everything that you do. Say you’ll finish a task in a week and it takes you a week and two day. Take the same scenario but you say it will take you a week and a half. You’ve just turned yourself from being the wiener to being the winner. And it’s the same thing in the two stories. Get your client involved, let them invest in the cause so there’s buy-in from both side of the coin. One of the great things my previous employer preached was that good news travels fast, bad news should travel faster.

Project Slider Bars

I’m not sure where I got this idea implanted into my brain, but I would like to give credit (if I could remember who it was) to the person that thought of this description of a software project. There are basically four sliders within a project, quality, time, money and scope. All four are inter-dependent. The sad truth of it is as a developer you only have control of one of those slider bars, quality. So what is a developer to do if a project is late? Naturally work harder, put in some overtime and get the job done. So what happens if a project is REALLY late? The only slider bar that you have in your control is quality and what happens? Quality suffers…

This is by far one of the worst mistakes a developer can make, because what’s going to happen is that the entire team (including management) is going to pay for it over and over and over again in the long run. I remember a study about cost and the later it takes to fix something in the project timeline the more costly it will be for the overall project. So what is a developer to do? Push back; tell someone, people have to change their perception that this is bad news… This is GOOD news! It’s even better news if it can be identified early that a project will be late. Tell people, tell people early, tell them so they can do something about the other 3 sliders, which are out of a developer’s control. It also adds value to the team that their managers are supporting them – that they don’t have to work on crappy code – that, quality from a manager’s standpoint, is important (I’ve seen sometimes it isn’t). For those managers out there, stop saying “just get it done”. You may not realize it but you’re going to pay for it in the end. As a developer you really don’t have a lot of control over anything other than quality, make that as one of your high priorities. There will be pushback of course from above if something is late. Be strong, set those expectations early, and tell someone that has control of the other sliders if something is going wrong; it really isn’t bad news…

Delivery Pains

Handoff of any kind within the software industry, and probably within every industry, is possibly one of the most important aspects that you have to take care of. It’s really about perception. I’ve never believed in throwing things over the wall and hoping for the best. If I do have the control, I will take extreme care when I write a bug report to developers and the testing team, or handing of a software drop to a client. There are just so many things that can go wrong. I’ve had the privilege of working on a lot of version 1 type software where a small little setting here or a specific hardware configuration there might be the perception changer of what works and what doesn’t work. I’ll have to say that letting the testing team or the client bang their heads over and over again trying to get your software to work properly is possibly the most frustrating thing imaginable. You then have to remotely debug their setup which takes days due to the process of pushing logs and instruction between the two, wasting your time and the client/tester.

If you’ve performed a fix for a QA bug report put as much information as you can into the unit testing that you’ve done, be available for them to bounce questions off of you. When you have a software drop be there for the client, maybe even drive or fly down to their offices and work remotely for a day or two so that the software transition is smooth. This really could be the deciding factor in the perception of the software working or not working. Truthfully, how much does it really cost for a short flight, a night stay and some senior developer time. It really adds value for you as a provider to the client that you care about delivery, you want to build a solid foundation with them with face time, and ultimately you make their lives easier just being around.

So the next time think about delivery, are you doing all that is necessary for a smooth transition of information passing? Is it very stressful during code drops? Do you have to put out fires right before and after every release?

Maybe it doesn’t have to be that way…

Maybe it’s your delivery…

So...What's Next?

I've been in the software industry for a short amount of time compared to some of the veterans out there that are going on 15-20-25 years, but I've come to a point in my career where I'm asking myself what's next? I know some of you can agree with me on this...

My vision of a software dev. is it's a stepping stone to being something more. I don't want to pigeon hole any career path or insult those gifted developers that have been in the business and will be in the business for most of their career, but I really think there are only three major avenues to follow after the software dev gig. Project Management where you're getting away from software, managing timelines, budgets, teams. A software architect/CTO - driving the technology of the company, designing some napkin scribbles and giving this down and saying "implement this... What you can't read my handwriting"? And the contractor/consultant route, which sort of ties into the software architect role, where companies hire you for time and material for your technical expertise. I don't want to get into mISV or building your own company, I think that's partially separated for working for 'the man'.

I question to myself, what if I don't want to follow these paths? All of the above, to be really good, needs an inherent personality trait (which can be partially learned), but one must have an affinity for it. So what if you don't fall in to any of those categories? What if none of those options really appeal to you?

So what's next...?

Personally I don't know - maybe in the next few years I'll figure that out and head down that path.

It's a Friday - maybe one of you have some thoughts on the subject?

Being the Hero

Even as a little child I've always wanted to be the hero in the story, now who wouldn't. Slay the bad guy, get the girl, praise and grandeur bleeding from every where... It's surreal... This unfortunately applied to software development early on in my career. Push through to get that software release, solve problems that people have been scratching their heads on for days. Be the 'go-to' guy. This was fuelled by a mix of challenging yourself to the brink, wanting the praise and gratitude from other co-workers and ultimately just a longing to be special. So, did I get the girl? Slay the bad guy? Sad truth is... no. I want to say flat out that it's OK to be the hero, but there's this fine line that one should never cross.

So.. what happened?

I burned out... I was serving up every morning a shot of indifference mixed with a side of impatience and really nobody could do anything about it. Nasty - I know. Nobody wants to be in that pocket and no vacation or time off could remedy this (when you get back from vacation, it's still going to be there).

What I realized was that being the overboard hero wasn't helping the team but actually hurting my co-workers. Long stretches of overtime is not something any dev should take, this just means that the project was poorly planned from above (push back). Being the go-to guy for everything under the sun depleted others on the team from being autonomous. Sometimes people have to grind it out themselves (with a little guidance that is), it will be better for them in the long run. Developing an organic symbiotic relationship with the other members on the team where you share ideas and techniques is a better solution than being the point man on everything.

Rule of thumb these days, pre-plan your projects and hash them out, design and timeline wise (there's actually a statistical formula per project type). Don't push your devs for too much they'll hate you in the end for it. Intrinsically show the value of their work and how they grew within the project they were on. Follow the "Don't Live with Broken Windows" mentality. Expect knowledge to always flow equally between each team member. And most importantly go with your gut and don't be afraid to be vocal about it.

It took me a year to get out of that burned state... Will I ever get there again? A resounding 'Hell No' - there's more important things to life