?

Log in

No account? Create an account

[icon] A poll for software geeks - Patti
View:Recent Entries.
View:Archive.
View:Friends.
View:Profile.
View:Website (pattib.org).

Security:
Subject:A poll for software geeks
Time:04:47 pm
Poll #1503826 A poll for software geeks

If you have to put ugly hacks in the code, you can trace the problem back to an earlier bad decision about code or data architecture.

Always true
4(11.1%)
Almost always true
28(77.8%)
Almost never true
3(8.3%)
Never true
1(2.8%)
comments: Leave a comment Previous Entry Share Next Entry


adb_jaeger
Link:(Link)
Time:2009-12-27 12:57 am (UTC)
I have had the luxury over the past month or so of having some free time to refactor a couple of modules (that I originally wrote). I was amazed at the amount of cruft that disappeared when the model was corrected.

I can't say "always true", because sometimes the requirements just change too dramatically mid-stream, and you don't have time to re-write and re-engineer everything, you just need it working yesterday.

(Reply) (Thread)

(Deleted comment)

sfogarty
Link:(Link)
Time:2009-12-27 01:25 am (UTC)
If you had said 'wrong decision', I would hvae said almost always true. But very often the currently wrong decision wasn't an earlier bad one: the right decision at the beginning of a project may turn out to be wrong later.
(Reply) (Thread)

(Deleted comment)

adb_jaeger
Link:(Link)
Time:2009-12-27 01:54 am (UTC)
Depends on the situation...... I worked for 11 years for a hedge fund.... sometimes, we'd want to try something different in a model, and if we thought we could make money, you'd hack it up first, and fix it later, if it did make money.
(Reply) (Parent) (Thread)

(Deleted comment)

sfogarty
Link:(Link)
Time:2009-12-27 06:09 am (UTC)
Things change over time. You cannot outline the entirety of a project at the beginning. You do not always know what the right model will be. Going back and refactoring is part of all this.
(Reply) (Parent) (Thread)

(Deleted comment)

sfogarty
Link:(Link)
Time:2009-12-27 06:33 am (UTC)
No, it is what you do instead of going back and refactoring. The question is if putting in an ugly hack is necessarily a sign of earlier bad decisions: no, it may just be a sign you need to refactor now.
(Reply) (Parent) (Thread)

(Deleted comment)

jpmassar
Link:(Link)
Time:2009-12-27 02:28 am (UTC)
There's no middle ground here.

And I'm not sure whether you mean 'back to an earlier bad decision about code or data architecture that you or someone in your group made', or whether you mean a bad decision made by anyone, at any time. Like creating XML in the first place. That's not my fault, as far as I know, and yet ugly hacks abound.
(Reply) (Thread)


abostick59
Link:(Link)
Time:2009-12-27 02:30 am (UTC)
I would have liked the option "Often true."

Sometimes the earlier bad decision is about something outside the scope of code or architecture. Project scheduling, for example.
(Reply) (Thread)


whipartist
Link:(Link)
Time:2009-12-27 02:34 am (UTC)
I intentionally chose not to include a wimpy middle-ground option.
(Reply) (Parent) (Thread)


catness
Link:(Link)
Time:2009-12-27 03:16 am (UTC)
Thus requiring ugly hacks. ;)
(Reply) (Parent) (Thread)


jpmassar
Link:(Link)
Time:2009-12-27 04:43 am (UTC)
Poor design.
(Reply) (Parent) (Thread)


prock
Link:(Link)
Time:2009-12-27 06:39 pm (UTC)
Seconded. :)
(Reply) (Parent) (Thread)


yayhappens
Link:(Link)
Time:2009-12-27 02:46 am (UTC)
Most of the time the coding that I am doing mods to is pretty clean. Mine start out pretty clean too but after having to hack so many lines in so many places it starts to get ugly by my own hand, but yeah...most always it's me and not the original programmer.
(Reply) (Thread)


adbjupe
Link:(Link)
Time:2009-12-27 02:47 am (UTC)
And if you have to decide between bad code or bad architecture it's something like 95% bad architecture. Bad code you might actually be able to fix relatively short term instead of putting in the hack.
(Reply) (Thread)

(Deleted comment)
(Deleted comment)

filthy_habit
Link:(Link)
Time:2009-12-27 04:44 am (UTC)
In defense of my lonely self, there is no such thing as an ugly hack in my world. I've seen some pretty horrible code written over the years, worked on some software packages that made me vomit because of the stupid concepts used (try figuring out what the hell is going on with spouse accounts in CMS, for example, using multiple occurrence data structures and a bunch of other unnecessary hoo-haw). But I'll be damned if I ever wrote an ugly hack. My shit is beautiful!
(Reply) (Thread)

(Deleted comment)

rightkindofme
Link:(Link)
Time:2009-12-27 04:46 am (UTC)
Noah says, "It depends a lot on the speed at which you are coding."
(Reply) (Thread)


prock
Link:(Link)
Time:2009-12-27 06:42 pm (UTC)
I think this is the best answer.

Often, when developing new code, experimentation occurs in order to solve the actual problem. Often the basic design is fine, but lacking implementation insight. So the problem usually isn't up front design that's lacking but refactoring and iterative redesign that's missing. That happens most often when deadlines are driving the schedule.
(Reply) (Parent) (Thread)

Mark Rafn [dagon.net]
Link:(Link)
Time:2009-12-27 05:09 am (UTC)
Always true, trivially. Every real decision about code or data architecture has bad aspects due to conflicting requirements, and all shipping software has ugly hacks due to this.
(Reply) (Thread)

(Deleted comment)

whipartist
Link:(Link)
Time:2009-12-27 08:48 am (UTC)
Your Synaptics days ran for cpu-months? OK, I'm teasing... it's a tortured sentence, but I can make sense of it.

Hacks like that are quite rare, and becoming increasingly rarer. In these days of cheap, plentiful CPU and memory, there's rarely a need to optimize the hell out of an inner loop.

A friend of mine wrote games for the Atari 2600. Listening to him talk about what he had to do for that makes me nostalgic for the days when programmers worked close to the metal. I might or might not be the only engineer in my company who could debug at the assembly level, but I'd bet large sums of money that I'm the only one who could use a bus trace. Come to think of it, I'm not even sure I could do it anymore... it's been 15 years, and CPUs have changed quite a lot.
(Reply) (Parent) (Thread)


thorfinn
Link:(Link)
Time:2009-12-29 03:04 am (UTC)
Software development people our age are probably the last generation that understands the bare metal. We grew up playing with it, since then, nobody else gets it.

I often find better junior developers out of electronics engineering grads and mathematics grads than out of computer science grads as a result. :-/
(Reply) (Parent) (Thread)


adb_foldem
Link:(Link)
Time:2009-12-27 10:29 am (UTC)
Didn't answer poll, but did read commentary. It's been (more than) a few years, but most of the time back then hacks were caused by changing requirements from the end user, Not still true?
(Reply) (Thread)


mjosephb
Link:(Link)
Time:2009-12-27 12:58 pm (UTC)
Sometimes the ugly hacks are required because of bad decisions about code or data architecture from the OS/Database/Middleware vendor.

Or lately because the OS provider has decided not to make public the entire API and you have to create ugly workarounds just to get a GUI that almost looks like their native apps...
(Reply) (Thread)

[icon] A poll for software geeks - Patti
View:Recent Entries.
View:Archive.
View:Friends.
View:Profile.
View:Website (pattib.org).