views:

144

answers:

5
+2  Q: 

deadline shortcuts

Most of the time I write very maintainable and well design code(even at home). However I just wrote db + msword report app for my friend and code is really bad - lots of code duplication and development speed driven db design - I just dont care at all about this code. I just wanted to finish it fast and go to sleep.

I came up with some faster development tricks .. for example i needed to persist map in db, but instead of what i do at work(most of the time you need to create new table for that with two fields and then map it to ORM) I just created new field in table with properties seperated by semicolon. Development speed of that was like 5 much as fast. Even parsing at client side took almost no time to write. it can be refactored later, but i feel that it wont.

What faster development shortcuts do you recommend when deadline is close?

+4  A: 

Man o man, storing entity objects as comma delimited entities in one field is very poor practice even if you are on a tight schedule. You should never ever do anything like this whether you are at home or work or wherever. It may not affect you for the time being but when you get into reporting, pulling data, or making any sort of relationships between other entities with this data you simply can't :(.

My advice about deadline shortcuts, is this particular type of shortcut should be avoided at all costs.

JonH
+1. Normalization isn't everything, but 1NF really should be an absolute minimum regardless of what you're doing, unless you have an **extremely** good reason to avoid it for some table - and no, not caring is not one of them.
Michael Madsen
I think when you say that you are over-designing. what is the diffrent of changing it now and changing it when it needs to be something more? it might be removed with next version or refactor with next version, why waste time now? only unused code doesnt change.
martin
+7  A: 

A deadline short-cut that leads to problematic code isn't, if you think about it, a short-cut at all. I realise that you're not invested in this code, but when it breaks later -and it more or less certainly will at some point- you're going to spend so much more time debugging because you took a, for you abnormal, crazy short-cut.

It's understandable, but it's not a great idea. Or, most of the time, even a time-saver.

David Thomas
In theory you are right, however since only I work with this code it wont break, i even have methods - void store(id, map), map read(id) to bypass any problems with parsing. many times we look for perfect design when its not needed and here i just used old-school write/read from file technique when you design the file - however here its database. I might need to refactor when I want to do group by that field, but not sooner.
martin
That's a *part* of my point, though: if you have to refactor later it's likely that will cost you more time than you saved.
David Thomas
but i can refactor it when there is no deadline and than it cost me nothing.
martin
Surely it'll 'only cost you nothing' if you don't value your time? =)
David Thomas
hehe, i just value deadline time more than web-surrfing time.
martin
Yeah, you have that point. I just have this...instinctive urge to counsel *against* a programming kludge. In all honesty, to avoid deadline-panic I just tend to write a spec, get that confirmed or re-write-to-suit, and then code to that and the agreed deadline. And -for what it's worth- I *always* add a week's buffer zone between when I think I *can* finish and when I *agree* to be finished. Sort of the Scotty principle of time-management...
David Thomas
@martin: Look back over your experiences and see if you can remember a time when you leisurely went back in to a project and refactored out the code debt. My experience has been that due to new priorities, new deadlines, or simply lack of motivation, later never comes. You and others will be maintaining kludges indefinitely.
TrueWill
Regardless of whether you value your time or not, the next time you have to touch this code, you will be cursing yourself.
Wade Williams
+1  A: 

There are two great aphorisms regarding this. One from China:

When you are most in a hurry, slow down.

And the other from the Amish:

The hurrieder I go, the behinder I get.

Carl Manaster
Those are some great aphorisms.
David Thomas
Those aphorisms are great for many things, but i think here they dont apply. here slow down = stop and forget about the project.
martin
+2  A: 

What faster development shortcuts do you recommend when deadline is close?

There are lots of fast development shortcuts, but the ones I would recommend when the deadline is close is to reduce the scope of the project and dedicate your time testing and fixing bugs.

If the deadline is not close, the fastest way to develop software is to prevent three major software problems: schedule slip, quality deterioration, and irrelevant software. Many well known methodologies and guidelines like Scrum, XP, Joel Test address these issues.

Edit: Hiring really smart people and letting them use OCaml (see ICFP Programming Contest) could also work.

Edit2: I wasn't serious about hiring smart people or using OCaml. The Mythical Man-Month points out "Assigning more programmers to a project running behind schedule will make it even later."

eed3si9n
good points, however you are looking at it from manager point of view and sometimes he might be blind. at work is something is needed as fast as possible we have special person that bugs you for it every 2h. You can take programming shortcut and if you care comeback later and change it. if you forget about it than it wasnt that bad of idea. code-generation is another tool, sometimes its easier to generate a lot of code than to read a book on how to do X in framework Y.
martin
A: 

Simplicity! Code Reuse!

Langali