How to write efficient code despite heavy deadlines

Question

I am working in an environment wherein we have many projects with strict deadlines on deliverables. We even talk directly to the clients so getting the jobs done and fast is a must.

My issue is that i'd always write code for the first solution that comes to my mind, which of course I thought as best at that moment. It always ends up ugly though and i'd later realize that there are better ways to do it but can't afford to change due to time restrictions.

Are there any tips by which I could make my code efficient yet deliver on time?

Answer 1

If the code needs to be maintained, explain that additional time is needed to make the code more maintainable, which will save them money on the backend. In other words, make maintainable code a requirement.

If they don't care about that, I don't think you need to do anything different, other than getting better all the time and doing the best you can to incorporate best practices whenever possible.

Answer 2

Okay, this may sound a little crazy but I swear it works. It's not just for programming, it's a recipe for increased creativity, concentration, and memory:

• Eat well
• Meditate
• Get plenty of sleep (7-9hrs depending on the person)
• Nap whenever your brain is fuzzy
• Go to sleep with an unsolved problem. Don't end your day with everything complete. Leave one difficult task pending - your subconscious is remarkably effective.
• Wear comfortable clothes
• Exercise
• Take time to do rote mental exercises - sudoku (not programmed), crosswords, math drills, spatial puzzles, etc
• Perform objective experiments on yourself to see which of your behaviors impact performance (you'll need a reliable way to test performance for this to work).
• Attend to your spiritual health
• Cotton underpants
• Attend to your sexual health
• Make time for your family and friends
• Become proficient at something outside your profession (music, cooking, sports, etc) and socialize with other people doing the same thing
• For some people, a pet is a must

Before you know it, you'll see a marked improvement in your programming productivity and quality of solutions (not to mention improvements in other areas).

Sources:

1. Your Miracle Brain: Maximize Your Brainpower, Boost Your Memory, Lift Your Mood, Improve Your IQ and Creativity, Prevent and Reverse Mental Aging
2. The Quantified Self
3. Seth Roberts - in Scientific American

Answer 3

It's counter-intuitive, but you probably need to slow down. When you implement the first solution that comes to mind, you create a lot of extra work for yourself down the road. By "down the road", I mean as early as later that afternoon. The problems you create for yourself don't take months to develop. Consider your options. Type less and ponder more. Even in a short project, you'll find that less coding may actually speed you up.

If your clients cluster in specific industries, try to build projects that have re-usable components. Not writing code is faster than writing it.

From your client's perspective, this smells a little like "Fast, good and cheap, pick two". Sure, we all want what we desire immediately, but your clients need to consider if this is best in the long term. Try to articulate the trade offs and help them make good decisions.

Answer 4

Look for another job.

You will find that after about 6 mos. to a year that you will have no pride in the work that you have done. Further, you will have spent no time being able to learn about new techniques, technologies, or frameworks -- so after a year, you will not have been able to keep up with the new technologies. You will be a worse programmer relative to the market after a year than you were at the start.

If too much time passes (say a couple of years or more), you will have a very difficult time getting hired anywhere except for these kinds of fast-paced jobs where quality code is not appreciated, only speed.

That said, as a "real world" learning experience, there is something to be said for the fast paced environment, but I would say that about 6 mos. is enough. Beyond that, you should look to hook up with a couple of recruiters and seek someplace better. You'll be much happier, honest.

Answer 5

From your clients view code efficiency may not be that critical, and can be quite expensive. These days time spent making code needs to save hours of CPU time to justify an hour of your time. For most programs efficiency is not that critical. Even for those where it is, most of the code does not need to be that efficient. Given the choice my preference would be for an easy to maintain solution rather than a more efficient more difficult to maintain code.

Taking time to plan your coding before you start may give you time to evaluate solutions and consider alternate approaches. This should save you time in coding and an testing. I have found that often simpler code is more efficient.

Layout the code cleanly using as many lines as necessary. Complex code can confuse the optimizer and may result in slower code. Modern compilers are very good at optimizing the code, trust it to do its job.

Accept that good enough is good enough. When you do come up with more efficient approaches, make a note to yourself. If you get some time, compare a few of your more efficient designs against the ones you implemented. Try them in the small (just the effected code) as well as the large (the program which uses them). This will give you a feel for when a more efficient approach is appropriate.

Many people consider premature optimization a bad approach. It can be costly to implement. Unfortunately, many premature optimizations actually are not efficient as the code they optimized. To properly optimize code you need to instrument the code before and after the change to see if you really have improved efficiency.

Study techniques that help you write cleaner code with low coupling and high cohesion. In many cases, reducing complexity increases efficiency. Techniques that help you minimize the bugs you have to fix during development will help you deliver faster. This may free up time for you to test alternate approaches.

Answer 6

Robert covered the most important aspects.

I have worked in such environments, wherein the code does not (cannot) live for more than six months. There are a few thumb rules that I can think of:

1. Use open source libraries, third party solutions, etc.,. The learning involved is paid off by less maintenance and debugging. However, if you are stuck with a buggy library, you are doomed.
2. Stringently ensure your design is extensible. A mandatory requirement: most of the work comes as improvements, not building new features.
3. Build rigorous test plans. Get a QA, or automate tests to ensure regression testing.
4. Use smart tools - IDEs, code generation utilities, etc.,.
5. Keep things as configurable as possible. (Flip side is increased testing efforts)
6. Improve your typing speed :-)

Answer 7

In the design phase, talk to colleagues.

Discuss your design and how you want to do it, and have them scrutinize your decisions. If and when you all agree on what's smart, you have a much sounder design.

Answer 8

Practice. Practice at writing good code until it becomes second nature. Then practice at coding faster. Then practice coding better. And when you're done...practice some more.

Answer 9

My issue is that i'd always write code for the first solution that comes to my mind, which of course I thought as best at that moment.

No, that's not your issue. That is a virtue. It's doing the simplest thing that could possibly work. But it only works when combined with refactoring. It's a continuous process: doing the next simplest thing that could possibly work, over and over again, so that your system is always an expression of your current understanding of the solution space.

Your issue is that you have management who don't understand the true lifecycle cost of software systems. 90% of that cost is maintenance, not initial implementation. Testing and refactoring are our best tools for reducing the total lifecycle cost of a software system. If your managers won't let you do these things, they are irresponsible and need to be retrained. Or you need to find a new job.

Finally: as I have said before*, you need to learn how to say no.

* How to code on a very tight schedule?

Answer 10

If they fixed scope and time all you can do to make the deadline is drop quality.

If possible drop external quality, visible to stakeholders, do not compromise on internal quality, stuff that hurts your habitability in the codebase.

I really don't think self improvement is going to help you any bit in this situation. If anything then, sorry to say, usually it's assertiveness.

Try to get a foot in the door when work is estimated. How can your boss estimate how long -you- take to do something?

Bring choices to your boss and/or customer. Too often it's developers themselves who choose to drop quality without communicating anything. Late projects/work is very common and typically 'managed'. Act on it on time, warn people if you see a missed deadline coming.

They can't cut scope or move the deadline if you tell them nothing.

If you are going to compromise on quality in any form, try to let it be their decision. Give them stuff to weight against each other.

Some stuff only YOU can decide. If you just about got it to work. But it's very unmaintainable. Perhaps you are unsure if it works in all cases. Don't tell anyone you are done. Redo it. Very often it's a decision only you can make. Either because the problem is very time consuming to articulate or you have a non-technical manager.

Sometimes it's part of your work ethic, would you just stitch a patient up without washing your hands cause 'there is no time'?

Above all, remember: there is no later.

Answer 11

I am a .Net developer working on web applications.

The things I have started to do is -

If it is C# code, I try to write that code in LinqPad first (if possible).

If it is Javascript code, I first write that code and test it in jsfiddle/jsbin (if possible).

I found that this helps with the quality of code but does not slow me down (and in several cases, I found it to be faster).