How to code on a very tight schedule?

Question

I'm working on a project that has very tight schedule. I don't have much time to code and test (even though I work more than 12 hours everyday, it's still delayed), and the result is very fragile. Its code is also very dilemma.

This program is used by all offices in our customer's company, which is located in many countries. I regularly get phone calls at midnight about errors from our user/tester or about them not knowing how to use some features.

After three years on this project, I feel very stressed and I can't sleep well because I'm very worried about errors and phone calls.

I have a few questions:

1. For three years, all the code I've written is just the perfect usage scenario code (so it break easily). It's poorly designed and doesn't have any unit tests. I have lots of problems because of this fact. Therefore, I want to know whether is it's feasible to write code that works when the project has a very tight schedule?
2. How can I write better code in the same amount of time?
3. How can I clear my mind and don't get worried about work when I go to sleep?

Answer 1

Ban phone calls

If your users are across the globe they surely can't expect you to pick up a phone when it's 4 AM in the morning and you're in bed. I would ban phone calls and switch to other means of communication that can serve this scenario better (email or some issue tracking DB). But even at the office make a scheduled phone accessibility schedule. Otherwise you can't do anything during the time you're at the office.

This will get you valuable sleep and rest.

Tight schedule

If this project has been tight scheduled for three years, somebody must have suspected something that things aren't really working. Maybe it's about time somebody tells planners something and especially your users/client and your managers that this is a death-march project. It's been in development for three years, it's delayed and it's full of bugs. Plan should be completely re-evaluated, existing code should be refactored and new features shouldn't be developed until numerous issues are resolved.

Order from chaos

Establish a development methodology that will make things predictable and bearable for you. If you're a developer then serving phone calls as they come in doesn't allow you do do any work. Every interruption takes you 15 minutes to get back to where you left off. Phone calls should be off. At least on your desk because you're a developer. If you can redirect phone calls to someone else that won't bother you after every call than do that.

Establish some sort of incident/bug database. Take some time every morning when you get to work and prioritise new incidents (yourself, your team or with your client/manager). Try to solve them in this priority order afterwords and don't even try to think of phone calls.

What if

What if you can't turn off your phone and you can't tell your users they can't call you whenever they want? If you have your user's phone number I suggest you do the opposite: when they call you, make a notice and inform them you'll call them back when it's solved. Then call them back when they're sleeping. If they tell you that they're sleeping, remember their reply and use it when they call you in the middle of the night the next time. People usually understand their own language better.

If they use office phone and you use a mobile phone so you can't call them outside working hours and they can, then start switching off your mobile phone after you leave the office. You've been there for 12 hours and you deserve to be off work. If the mobile phone is your personal one, then your company should get you a new one and you should inform your users/clients about it. If they start calling you on your personal one afterwards (because they can't reach you on your business one you either:

1. don't pick up
2. have it answered by a friend of yours informing them of the wrong number or that the original user of this number isn't using it any more.

The most important thing

Don't develop any new functionality until you resolve existing issues. At least high and medium priority ones.

Answer 2

Unless you're the only person on the team - in which case, you're probably more than half-way down the road to burnout - take turns with 'the pager'. That should lighten the load for now.

Then you need to pitch to management that they need to schedule a phase to pay down the technical debt - that means testing, code cleanup, refactoring. And it needs to be scheduled soon. Generally, this means that for a while there is no new code that isn't a refactoring or a test. If not, it's just going to get worse.

Once in that phase, you pick the most troublesome sections of the codebase, refactor it, clean it and write tests to test the shit out of it. Once the calls stop, or can be handled without the devs going crazy, then you're ready for another phase of features (if that's what they want). At this point, you write tests with new code, and keep running the regressions. Right now, the software sounds like its on the path to a re-write.

Selling points for your conversation with your boss:

• Automated tests can stop or significantly lessen regressions
• Focusing on stability means that the users will have fewer work delays/stoppages
• No more midnight calls means they aren't paying overtime
• No more midnight calls means that the devs aren't going to burnout as fast

Let's be honest though. Up to this point, your company hasn't thought that this is a big enough problem to do something about; you're going to burn out. Sounds like, nobody in management has any real development experience. Start looking.

Answer 3

While there may be some techniques that will allow you to achieve small gains in productivity, a 5% increase in work output is worse than useless to you right now. The real skill you are missing here is simple and foundational:

Learn how to say no

Say no to all the unreasonable expectations you already know you should be refusing. You know what they are. That much is obvious. If you can't say no now, find a job where you can. Smart employers will find this skill desirable.

Answer 4

Begin by understanding that your project is going to fail if nothing changes. This is the most important step to doing what you need to do. A developer cannot sustain 12 hours a day of effort and be able to produce useful code. You will get to a point where you create stupid mistakes and actually lose progress because you have to start each day fixing what you did the day before. It sounds like you are already there.

There are two major problems that need to be addressed before you can have sanity again:

• Management needs to know that what they are doing is not working. Continuing to repeat the same mistakes will produce the same results. Something has to change.
• You need time to fix what you already have. That means you need time to plan your attack, and you need time to work on it using 8 hour work days.
• You need to change how you work. Understand that the more stress you have, the more tunnel vision you have. You can't think of creative ways to address the problems or even think about what happens if there's a problem when you are stressed like this. Not to mention you have an increased chance of serious health complications. Find ways of releasing your stress, and find ways of reducing your stress.

In order to fix your situation you need management buy-in. The problem is that they are not feeling the pain, and you don't want to end up in the hospital with a stroke to get their attention. The first step is to explain to your management where you are, and the pressure you are under. If they don't get it, go up another level of management. Or possibly describe your working conditions to the HR department. Requiring you to work more than 8 hours a day for extended periods of time may be a violation of law, and the HR department will know for sure.

Assuming management hears your plea, you want to take the following actions:

• Stop the bleeding. No new features, and someone else handles the service calls. You need to be focused on the task at hand.
• Identify the most severe bugs that need to be fixed, and try to figure out how long it will take to fix them. This is a rough estimate, and it is better to have larger numbers than lower numbers. To account for meetings and interruptions throughout the day, your management needs the estimate based on working on it for 5 hours a day. This leaves 3 hours for meetings and interruptions.
• Get management to agree to the revised schedule for these critical bugs.
• Get management to agree to have someone else test for you. This is not admitting you can't do your job. This is simply providing some quality assurance so that every release is better than the last.
• Now you fix them. Write unit tests to reproduce the problem, so that you know when you've got it working. More importantly, you will know if something you did in another place broke it again. Refactor to make the code work better.

Once you've got that critical bug fix release done, it's time to plan the next one. All features and bug fixes need to be prioritized, and releases need to be planned around a subset of the pending workload. You'll find as you bring some sanity in to your work life, your stress levels will go way down, your quality will go way up, and you'll be more efficient overall.

Answer 5

You appear to be suffering from what I consider to be a case of False Economy, and the longer you adhere to those things that don't work, the worse your problem will get.

Some Key Indicators:

• What appears to be an unrealistic schedule.
  • I assume a poor understanding of sound development practices on the part of management.
  • I assume a lack of understanding or support from management.
• Working 12 hours per day.
• High levels of Stress.
• Lack of sleep.
• Anxiety.
• Poor attention to design and code quality.
• A lack of a unit testing safety net.

I want to know whether is it's feasible to write code that works when the project has a very tight schedule?

The short answer is yes. The long answer is it's complex, and will require a massive change in perceptions on behalf of management and possibly the customer also, and a Herculean effort on your part... but I'll come back to all of this in a moment.

How can I write better code in the same amount of time?

Realistically, you can't if your assumption is that you can do anything that will save you time and still get a perfect result. You need to apply techniques that will increase the time it takes to implement your code because you would need to take time to focus on getting the detail right. This takes time, and it is here where your false economies are hurting you the most. However, by doing things in a better way, you improve the quality of your code and that in turn will result in reducing the fragility of your system. Again, I'll explain this further down.

How can I clear my mind and don't get worried about work when I go to sleep?

Anxiety causes a lack of sleep, and losing sleep creates anxiety. This is a vicious circle if ever there was one, and if left unchecked will likely lead to anxiety's evil twin, Depression. Chronic loss of sleep, which I assume is likely combined with a lack of exercise and also likely poor nutritional habits, all is likely to result in Chronic Fatigue. All of this is symptomatic of all of the problems that you are facing in your workplace, and the resulting problems you are likely to be facing in your home life. This is where the greatest evidence of false economies lies, and it is probably the most serious problem that you need to deal with first.

I also welcome any suggestions.

I should first state that I am not a medical professional, an you really should seek advice from your doctor before you act on anything. I will note however that I have lived through the experiences you have described in your posting, and I know how difficult it is to deal with, and how important it is to do something about it. I've lived through the depression, anxiety, chronic fatigue, stresses, and all the other little nasties that accompany them, so I will offer you some advice based on these experiences:

• Go to your doctor, and discuss your symptoms. Tell the doctor if you are tired, if you are feeling depressed or worried most of the time, if you get colds and flu often, and how you have been feeling physically. If your doctor is permitted, you are likely to be offered anti-anxiety or even anti-depression medication. Even if you feel reluctant to, leave pride at the door and take them as prescribed. They really do help, and allow you to find the strength to deal with everything that is to come.
• Seek a good psychologist to discuss your problem as you know it, and who can help you to explore how you feel about it all, and to help you to develop strategies to deal with the problem. Some of what you are asked to do may seem pointless, or a little wishy-washy. Do it anyway, because again, it really helps, particularly in teaching you specifically how to clear your mind.
• Avoid sleeping tablets unless you really need them, as you can become dependent on them and make you sleep problems worse. Personally I take them only when I am unable to get the sleep I need after a weekend, and that's usually when I have had a lazy and unfulfilled weekend.
• Look into changing your diet. Seriously cut out the caffeine as it only contributes to a heightened level of anxiety. Reduce your carbs, and balance your diet, and by that I mean eating more natural fruit and vegetables, reducing the amount of red meat you consume, and reducing fats and oils. Cut out the soft drinks, and limit yourself to a single cup of coffee per day if you find it impossible to give up. Diet is critical in helping you to combat the fatigue. Also, eat your last meal earlier so that you aren't going to bed on a full stomach.
• Exercise every day. Get a strenuous workout at least once per week minimum, and walk or cycle for at least 30 minutes each day to the point of working up at least a light sweat. This will help to tire you physically which will help with your sleep, and with your fatigue.
• Change your sleeping habits. Aim to wake up early for work, so you need to go to bed earlier than you may feel you want to. If you can't sleep, rest in a dimly lit room, and read something boring, and don't worry if you can't actually fall asleep right away.

Now that I've gone through all of the medically related stuff, let's look to what you can do about your work:

• Someone suggested using the Pomadoro Technique. This is also known as time-boxing, and I think it's a good idea. You basically concentrate intensely for 20-25 minutes, then you take a little break. I suggest you get up and move around for about 3-5 minutes, and look into the distance to rest your eyes. Try not to think about your tasks during that time. Get a drink, wander down to the bathroom, or simply move about in your office for a short spell.
• Depending on your relationship with your boss, find a way to meet and discuss your concerns that the work schedule is impacting your health. Put it to him that you don't want to risk letting the customer of the company down, and that you'd like to try and develop a strategy that can ensure you can continue to get your work done, but that this means you need to make time to address your health concerns as well. Use this as a last resort however, as it would be better to explain the false economies that are at work here, such as:
  • Fatigued workers end up with a greatly reduced efficiency, whereas non-fatigued workers have the capacity to do more in a shorter span of time, and I would try to source some figures and studies that you can use to back you up. With a good boss, you shouldn't even need this. The following articles may be of some use to you: article 1, article 2, article 3
  • Skipping testing and attention to some of the little details costs you later on. Look into the concept of Technical Debt as a starting point.
• Try to reduce your working hours to 8 to 9 hours per day.
• Book a vacation period, and get away for a while to somewhere quiet. Even if all you do is drive your car to the woods, and camp for a week. Seriously, do nothing for a while in order to recharge your batteries.

In terms of actual programming related stuff:

• Read the books Clean Code and Refactoring, and take the time to apply the techniques within. These will help you to deal with the issue of code quality. As I mentioned before, it will seem to make things take longer to do, however you will spend less time dealing with mess and problems that have resulted from how you may have worked previously.
• Find tools that you can integrate into your development environment in order to aid you in your efforts to improve code quality. For example, if you are developing in Visual Studio, using a combination of tools such as Resharper and NCrunch can contribute to massively increasing your overall efficiency if you use them religiously, and if you are already applying good techniques as described in the books I mentioned.
• Write unit tests, and use a test-first approach. This will seem to slow you down the most, however you will speed up your development overall when you have tests, as they can contribute to reduced debugging time, and give you the confidence to change tested code. Write your tests to satisfy requirements, and not to satisfy code. This will focus your testing efforts constructively, which should minimize time expended on testing.

Most important of all, you need to manage expectations, starting with your own. You are only human, and can only do so much at any given time. You need to manage the expectations of your boss, and have your boss 9or yourself directly) manage the expectations of your customers. This means seriously prioritizing the work you do. Allocate time for new features, and time for bugs, and assume your deadlines will slip. When dealing with the possibility of slipping delivery dates, promise only to deliver a set of critical features, and leave the rest of the features as "nice to have if possible". Next delivery date, you again go through this process, increasing the priorities of the prior delivery's "nice to haves", and so on. Build this into your development methodology as a minimum starting point, and then review after a couple of deliveries in order to see where you can tune your processes improve your efficiency. The greatest efficiencies will come from your life-style changes, however there are always little things you can do to streamline your work, like reducing overheads relating to documentation and communication between yourself and the end users.

Be proactive in all of this. Show your boss that you can both work together to really improve matters, which will ultimately reflect well on both of you, and the company overall.

Also, don't make any drastic decisions now. Wait until you've dealt with your health and your workload, and see how you go for a while. When your mind becomes clearer, and when you feel you are in a better place, then will be the time to decide if it's worth staying or if it's time to move on. What I am basically saying is to deal with one problem at a time, and leave the rest to stew a little until they need your attention.

Answer 6

If your schedule is tight you need to be compulsive about Don't Repeat Yourself. Identify most used methods, and ensure they are reused heavily.

Plan what you will be working on today, write it down, and stick to it. Try to limit what you need to remember at any one time to seven or less items.

I would go one step more and avoid repeating others work. Use the language's libraries whenever possible. Use third party libraries if possible.

It may seem like it takes more time to write but aim for methods that do one thing only. I limit a method to making decisions or doing things. The cohesion of your code should increase while coupling decreases. You should find testing is easier. This lends itself well to progressive decomposition.

Simplify as much as possible. Use templates, checklists, and whatever techniques allow you to avoid thinking about trivialities.

You will need to avoid interruptions. Each interruption will cost you about 15 minutes on the schedule. Protect your time.

If this is long term, go home when you find your performance starts to lag. If your are constantly working 12 hour days your performance is likely about what you would get working 8 hour days. You may not notice how badly your performance is degraded. Take the extra four hours to get some exercise and rest. See if you can get a nap mid-day or take some hours off after lunch.

Answer 7

If I were you, I'd talk to my manager and explain to them that the deadlines they're setting are unrealistic. If you just keep on working like that, they will think that everything is fine, they will not be aware of the issues you're having and you'll end up adding more and more poorly-written code to your system every day, which will complicate your job even further.

As an alternative, you could always switch to some other job :-)

Answer 8

Track everything you do

Take the time to track everything you do and how much time you and your team spend at it. This will end up being what you bring to management to show them that you need to do things differently. If you don't have the cold hard facts about what you are doing and how much time you are spending fixing problems that are reported by others it will be much harder to convince them that changes need to be made. Every hour must be tracked by everyone in order for this to be accurate. This is to be used to say that you spent 80 hours over the last 3 weeks fixing a system that could have been rebuilt from the ground up in the same amount of time.

Try to change things

Use the tracking that you have gathered and the great suggestions that others have made to put together a plan for improving the software. Choose the parts of the software that are causing the most problems. Put together the plan that you think will bring things to a normal manageable pace. Give it time to work.

Prepare yourself for the fact that it may be time to leave

If management isn't willing to change things and work with you it may be time to think about moving on. I agree with others that you are burning out. Start to prepare your resume and portfolio. Things may improve and you won't have to move on but if management doesn't buy in to making changes then move on. Your mental and physical health are more important than staying at a job that is taking so much out of you.

Answer 9

For the love of god, where's your project manager?

If you don't have a project manager to help you establish productive time, you need one. You need a person dedicated to sticking up for your development time, limit scope creep, manage expectations, etc...

You do a creative job for a living. If you don't have a barrier between your customers/users and you, how can you effectively focus on your development?

A good PM can be good for a lot of things...

1. To play the 'Higher Power' card:

Your users are bugging you for new features but you really need some time to focus on a bug-fix release. Who said you have to talk to the users? Is it your responsibility to write the contracts? Is it your job to manage customer expectations? Do you have final decision power to dictate the terms of the contract?

No? Then why are you solely responsible for interacting with the customer? Development is hard and takes a lot of concentration. You need the ability to reclaim development time and you can do so with a good PM and a good excuse.

Regardless of what your PM makes compared to you, if customers start bothering you about modifications outside of the spec just say.

"Negotiating changes outside of the specification is above my pay grade..."

It's a polite way of saying, I don't give a s***.

Follow that up by sicking the 'Scope Creep Dog' on them.

"If you want to make changes to the spec you'll have to get in touch with my PM"

Now, leave me alone. A user's ability to directly interact with the developers is allowed as a privilege that can be taken away. If that's not the case, your management is failing you.

2. Managing Expectations 101

Who in their right mind thinks you can work such a crazy schedule and handle 24/7 tech support. You need somebody to stand up for you because your time is valuable and should be dedicated to your craft.

This applies to customers as well as the company you work for. For customers, if they are overstepping you can always ask...

"Is this service written into the contract?"

If it's not, you have the right to reject requests then. Don't get me wrong, it's nice to go above-and-beyond to make your customers happy but it's equally important to let them know the difference between what's expected and what you're giving to them as a favor.

For the company you work for, you need somebody to carry the message...

"Is the work I'm being asked to do equal to my pay-grade?"

Ie, are they paying you 60k a year to spend 50% your time doing phone tech support which is a much lower paying position. This is a dangerous topic to broach so you need a PM you can trust to make a good case for you. The argument you should make to him is...

"I get paid 60K a year but half of my potential productivity is being wasted on menial work."

Or, you guys hired me and are willingly losing money on that investment by having me spend half my time filling a low grade position. Believe it or not, by maximizing your potential they can make more money in the long-run.

When it comes to business, it's a hell of a lot easier to get the company to change their position if you can present a win-win situation. You don't have to be a master of negotiation for this one to stick. Of course, if the company resources are limited then this may backfire on you.

3. Everybody could use a cheerleader sometimes

A good PM will naturally be a people-person. The core of what they do is people relations. A good PM will have the ability to tell your customer what they don't want to hear and still have them walk away happy.

They can also be a great source of moral support when times get tough. A simple morale boost shouldn't be too much for a good PM to handle if you ask. You need somebody on your side, or else your morale drops and the work feels overwhelming.

---

If you don't have somebody higher up in the organization that is responsible for managing expectations, your management is failing and the higher-ups are probably not even aware of how bad the project is doing.

That's the main reason I avoid working for corporations like the plague. I have been fortunate enough to work for smaller companies where I have somebody higher up I can honestly discuss problems with who will hold what I have to say in confidence and take action if necessary.

You need somebody on your side to help keep you in line with business requirements and manage distractions. If you don't have that and there's no hope of finding it in the future, good luck...

Answer 10

Wow wow wow ! Hold your horses cowboy!. You seem to have development all wrong there. You are missing some software fundamentals here while coding. Yeah brush up on your basics...life will be a lot easier.

Back to school time now

1. Rapid-Development-Taming-Software-Schedules*
2. Mythical Man-Month*

*Must Read

Answer 11

I like to make a TODO list, sort it in order of necessity, and stick to that order unconditionally -- even if I feel like procrastinating some tasks.

You'd be surprised how much time you can save just by reducing the time you spend wondering what to work on next.

Answer 12

Right now what you can do is to

• Pair up with a colleague
• All code you write or change, you must agree on being good enough. Preferably as pair programming, only do peer review if you cannot pair program.
• do not deviate from this!

This will mean that at least what you do from now on have been approved by TWO persons hopefully improving those bits of code.

What else can be done depends on management. You may want to show them this question with the answers!

Answer 13

Ban phone calls and implement a strict "bugs go to the bug tracker ONLY" rule. Then your first move of the day is to triage newly entered bugs, clean up dupes, prioritize, and get to work on bug fixes FIRST. And make sure your bug fixes actually fix the bug and don't introduce new bugs.

How do you do that last part? By retrofitting test cases onto your existing code. If you've got functions, test that they input and output what you expect, and that they fail nicely if you give them junk. Use some sort of automated UI testing to test the integration and performance front-to-back.

You're not actually getting out of bed at 3am to solve code problems, are you? If so, you deserve everything you get.

Answer 14

Try using the pomodoro technique. Also, I have 3 personal rules to know if I'm writing good or bad code that you might find useful.

Answer 15

You, and developers like you, are the only reason I can think of for requiring a software development license, like doctors and lawyers. That way your license can be revoked for not following minimal basic programming good practices. Not only would it protect the industry from incompetents, but it will also protect those competent programmers from managers who insist that their programmers not follow good practices.

FYI, practically everyone works on a tight deadline. However, those developers who know what they are doing follow best practices because it gets the work done quicker in the long run. Then they don't have to work 12 hour days for 3 years in a row.