|
What is Hacking the result of?
The thread on maintenance programming got me thinking about why people hack or more precisely what causes people to "hack out code".
By hacking I mean, literally piecing code together, forcing it to work, little by little until the whole program/function/procedure eventually works.
I can come up with a few reasons:
1. Lack of Knowledge
2. Poor Design or No design
3. Lack of Experience
4. Poor grasp of the language being used
5. Lack of knowledge on structured programming concepts
6. The programmer is Tired/has Personal Problems/Grudges
7. Lack of Time
8. Fear of being labeled a poor programmer because couldn't complete project in time.
9. Under-educated for task at hand
10. Not able to recognize patterns
11. Just coding as a "job" without any investment in becoming a better coder.
12. Worn out or drained from working on the problem.
13. The belief that the code will not have to be maintained.
14. The belief that all code that I, the programmer, write is "good, solid code."
15. Not able to hold a train of thought long enough to solve the problem or complete the given task.
16. The code was originally written by someone with no knowledge or formal training in programming.
17. The desire to make money off of an idea is greater than the desire to "do it right."
18. Lack of motivation and interest
There's probably many more reasons than this and I don't know which would be the number one reason, if there is in fact a number one reason, but my conclusion would be that it is simply the fault of human frailty. Everyone is susceptible.
Just Some Dude
Wednesday, February 4, 2004
Don't care. I was asked to put in a feature today so
they could continue the same broken behaviour
because they didn't want to deal with fixing the
real problem. See this all the time. See it from
experienced people from very good schools.
son of parnas
Wednesday, February 4, 2004
I've seen the title "hack code" applied to spaghetti code spanning hundreds of lines a function, to cleanly separated code that failed to separate everything out into n-tiers, to code that doesn't conform to the code-standards-du-jour, to code in the wrong language, etc.
One thing I've learned in my 10+ years in this industry is that there is an overabundance of bitchers who attempt to elevate themselves by waving their hands and proclaiming all code preceding them to be horrible, hack code. These geniuses virtually never actually generate any real volume of code themselves, as there's always some villain subverting their best laid plans. They seem to be fundamental unable to refactor existing code, even if given volumes of time, though after years of latency they'll still profess the flaws of the code before them to all who'll listen. I don't buy it. I think the people who bitch about code the loudest are the dregs of the coding world.
Dennis Forbes
Wednesday, February 4, 2004
I've pumped out some extremely terrible code under extreme deadlines. The problem is, at 4:00am, all you do is pump out code and you don't think about how to engineer it better.
When it's all over it takes about 5 minutes to realize a smarter design might have saved you a bunch of coding. But then, it's too late.
Of course, most of the discussion about hacking bad code comes from developers who really don't know what they are doing.
Almost Anonymous
Wednesday, February 4, 2004
There's always better code.
Wednesday, February 4, 2004
Hack has too many meanings to be really useful.
hacking code
someone who is a hack
and
hacking a system
are 3 different things.
www.MarkTAW.com
Wednesday, February 4, 2004
Amen to mr. forbes.
In my 5 years, I've gone from something akin to TOP, to dedicated preacher and changer-of-ways, and finally to my current self: I honestly try to get things right the first time in the time available.
But I recognize that there is never a fundamentally "right" architecture, class design, variable naming convention, bracket or whitespace style, column width, OS, programming language, or favorite flavor of coffee. I myself change my view of "the right way" atleast once a year.
I'm much more interested in building cool shit that solves actual business problems than arguing about the right way to do something. Anyway refactoring is one of the easier tasks in programming. If something is a mess, fix it! In a strongly-typed language, this is usually totally brain-dead work. ctrl+x, ctrl+c, edit, compile. repeat.
The constant bitching in this industry does not elevate anyone, it pushes the entire profession down to the level of auto mechanic.
Aaron Boodman
Wednesday, February 4, 2004
There's obviously not one right way to do things, but there are best practices that should be followed to make it easier for all involved.
As for creating new things that solve a problem, (i.e. writing new code), that is easy, maintaining someone elses code is the more difficult task. And yes, as has been noted in a different thread, there are reasons to "bitch" about other programmers work. Of course you can only "bitch" so long until you have to act.
SMALL CAPS
Wednesday, February 4, 2004
"maintaining someone elses code is the more difficult task"
This is an oft repeated statement, but personally I find it to be a myth -- I find that given a set of code with a concrete set of inputs and expected outputs, and historically documented behaviours, as well as the knowledge gained by examining the code, it is trivial to refactor from the inside out until it's all a beautifully re-engineered solution. It doesn't matter how you name your variables (modern tools make renaming them trivial once I've traced back to the origin), how much functionality you embed per function, etc -- it really isn't that difficult.
I've pondered the origin of this myth, that maintenance and refactoring of other's code is such a difficult task, and honestly I am prone to believing that in many cases it must be marginal programmers -- people for whom a different convention, such as brackets being at the end of the line rather than the beginning of the following line, critically upsets their ability to understand code. Obviously there is exceptional code that truly is hard to understand, but let's face it...most of us are rewriting the same boring business crap. There is no way it can be that difficult (especially at some of the higher languages), and harping about petty pedantry just seems so weak.
Dennis Forbes
Wednesday, February 4, 2004
Regarding:
17. The desire to make money off of an idea is greater than the desire to "do it right."
Isn't this what business is all about?
m
Wednesday, February 4, 2004
>> "Obviously there is exceptional code that truly is hard to understand"
This is the type of code I am referring to Dennis. Also it's not a proven fact that maintaining code is easier or equally difficult than writing new code.
Maybe you have been fortunate enough not to have to deal with severe situations. More power to you.
I think this means you simply haven't been "out there" enough. You haven't dealt with in-depth commercial systems written by novices. You may know your way around generic business systems but when it comes to systems that need to do something above and beyond reading/writing database records, such as graphics, typesetting, custom printing, device drivers etc etc.. I simply can't believe that you have dealt with these types of systems that were not written by professionals. When you do run into one, you make a post here and tell me that you were wrong.
SMALL CAPS
Wednesday, February 4, 2004
>> "Regarding:
17. The desire to make money off of an idea is greater than the desire to "do it right."
Isn't this what business is all about?"
==============================
That's the point. Business or getting it done to make money is put above coding the program the correct way.
Wednesday, February 4, 2004
Small
I've had the luxury of working on industrial embedded monitoring and control systems (on generic and custom hardware), low level assembly and interrupt handlers on archaic DOS machines, extremely large scale business systems, among others (both as new code, and as alterations of existing code). I've seen a lot of really academically bad code, but I have honestly never had that much trouble understanding the code because honestly what they're doing isn't overly complex. When I said complex, I'm talking about when what the code is actually doing is so tremendously complex (perhaps some extremely complex math) and it isn't properly documented.
Dennis Forbes
Wednesday, February 4, 2004
I've had the misfortune several times to bump into code which is essentially simple in operation, but is a pile of sh^t under the hood. Functions with bizarre names, so-called APIs that don't expose their interfaces clearly and global variables in abundance, some of which have multiple purposes, and attempts at "professionalism" with multiple levels of incomprehensible abstraction.
Time would eventually reveal how it works, but who has enough time? It's complex because it doesn't follow any of the standards you'd find in a text like Code Complete.
This is where the "myth" of maintaining being tough comes from. However, saying that - I know plenty of people who whinge about the lack of abstraction place as a complete hack. (Even though it's a responsive, robust solution)
The definition of a "hack": A piece of code you don't like. So, if you want to talk about the potential causes, you going to have to be a lot more specific about what you regard as a hack.
Shodan
Wednesday, February 4, 2004
"It doesn't matter how you name your variables (modern tools make renaming them trivial once I've traced back to the origin)"
That works pretty well until you encounter code where the same variable is used for multiple, very different purposes. This is the real hallmark of a hack job. The global variable customer_address holds the address of the customer part of the time, but in some sections of code customer_address actually holds the product code for the item being purchased, and in another section of code it's really the user's login password, all because the original coder was too damn sloppy and lazy to be bothered with declaring another variable. When you're trying to maintain some piece of code that has bizarre coding practices like this all over the place and is poorly documented or not documented at all, you are dealing with a true hack job and it can be a monumental task to navigate your way through it and figure out what the code really does.
Matt
Wednesday, February 4, 2004
Looking at your list I think we can summarise why a developer would "hack" a program together into two possible options.
* Bad developer (experience etc.)
* Bad project (time, foisting new tech on devlp with no training etc.)
Other than that, I don't think we need to drill down much more.
Shodan
Wednesday, February 4, 2004
"piecing code together, forcing it to work, little by little until the whole program/function/procedure eventually works"
Ok, this is the notorious 'Big Ball of Mud' methodology right? I think that sometimes, it is the right choice.
Tony Chang
Wednesday, February 4, 2004
I think you have your terms mixed up. In programming being hacker is considered a good thing:
How To Become A Hacker
Eric Steven Raymond
http://www.catb.org/~esr/faqs/hacker-howto.html
Hackers and Painters
Paul Graham
http://www.paulgraham.com/hp.html
Revenge of the Nerds
http://www.paulgraham.com/icad.html
The O'Reilly Series of Hack books
http://hacks.oreilly.com/
The Hacker FAQ
http://www.plethora.net/~seebs/faqs/hacker.html
Matthew Lock
Thursday, February 5, 2004
I agree with Mr. Lock. You guys are using a really odd definition of "hack" as it relates to the computer world.
John Rose
Thursday, February 5, 2004
You can't refactor a poor design. Refactoring, by definition, is changing the code without affecting how it works.
GuyINCOGNITO
Thursday, February 5, 2004
Not true. Refactoring is changing code without affecting how it works with *outside* world (other code), but not within itself. You CAN refactor a design, which Fowler even mentions explicitly in his book, althogh he doesn't recommend this.
Egor Shipovalov
Thursday, February 5, 2004
I agree with Dennis Forbes. Nearly all shit-code can be incrementally improved by refactoring, if you have the willpower to dig in. Most code I see is so bad that a top programmer could replace it in a few weeks no matter how long it took the monkeys to write. But that requires spending those few weeks of programming and also the time to gain a complete understanding of the behavior, which rarely has a complete external definition. The beauty of refactoring is that it's an incremental activity, and you don't usually need a full understanding of the entire bad codebase before starting, just good unit tests of the code you will refactor that day. But willpower is rare stuff.
veal
Thursday, February 5, 2004
John, Matthew, most of the people I've worked with have [also] used the term 'hack' negatively. "That's a dirty hack." "I put a cheap hack in quickly so it would fix it without any fuss." Don't draw any conclusions about the company I keep =)
At this point, I should say something like "eh?!!?!? a hack is a writer, you people are all mixed up"
Shodan
Thursday, February 5, 2004
There's a difference between the noun and the verb, even more so depending upon who's using it.
If its a tabloid newspaper it has nothing to do with writing software but subverting systems.
If some cherry cheeked breathless intern uses it then they probably mean they spotted some small bug in long established code and fixed it.
If some old codger like me uses it then it more likely means I've had to do something quick and dirty, it might not be very dirty for some but I'll know its a lashup.
Simon Lucy
Thursday, February 5, 2004
"Bad code" is a much over-used phrase/theory IMHO (which is not to say it doesn't exist).
1. If you say the other guy wrote "bad code", it sort of absolves you of responsibility for not doing whatever it is you are supposed to be doing, after all it's the other guy's and the bad code's fault - not yours.
2. When "bad code" is rewritten or refactored, it frequently comes out different, but not necessarily better. It's still "bad" but just in a different way.
Moving swiftly on, there are I think at least a few different types of "bad code".
1. There is "bad code" which is based on a fundamentally bad design. My personal favorite example was a huge database program written in C - that even though it had Oracle available to use, instead used huge ASCII text log files searched them with sed, awk, etc. The programmer who wrote this had to jump thru all kinds of hoops to make it work. His implementation code have been beautiful (it wasn't), and it would still have been "bad code", because the design decisions ensured the code was incredibly complex, and unable to perform to spec (e.g. a search took 1/2 hour) regardless of how beautiful the implementation of the design.
2. There is "bad code" which began bad as a lash-up, or demo, and just kind of grew. I think the example above, began like this. This kind of bad, can run thru to the design or implementation or both.
3. There is "bad code" which began okay, but grew and grew until it became bad. I think this is common with apps with long histories. Frequently the badness of this type of code, is overestimated.
4. There is bad code where the overall implementation of a design is bad. Examples might be disorganized code with no modular structure, vast functions, etc. Again badness of this type can be overestimated. Again, this is common with apps with long histories.
5. There is bad code where the badness is at a real fine level of detail. The design could be good, the overall implementation could be good, but the fine detail of the implementation could be bad (but the same badness can run like a million times thru the code). I'm thinking in my head of things likely badly named variables, the guy who used int for all variable types (pointers and all), the guy who never put any error-handling round his numerous scattered calls to malloc(10000000) and so on.
The last problem (5) clearly falls on the shoulders on the responsible developer, and lack of knowledge or care.
The other problems (1 to 4) is not a single problem, but could arise because of many reasons, some to do with the programmer, some to do with management, and some historical reasons.
As to solutions:
5. Educate the developer not to do it again. And fix the (most serious) problems one by one. Tedious but do-able.
3+4. Educate the developer if necessary, but remember it might be because of growth in the program, rather than fault of the programmer. Refactor the most serious problems.
1+2. Sometimes you can gut the bad aspects, keep the rest, sometimes you can't. In the example of this database/awk thing, in theory we might have been able to keep the GUI, and gutted the database search functionality (In practise, we couldn't because the GUI built AWK and SED command lines as you clicked buttons and so on, it was all mixed up!).
S.Tanna
Thursday, February 5, 2004
I find a lot of the hacked code I come across is the result of something that has been imposed not working properly.
In my case, the last "hacky" code I wrote was because of a bug in the G++ threading code... the documentation and reality differ "somewhat", so I've had to learn the real behaviour by experimentation...
In companies, this seems to happen because Management decide to buy a tool because it'll solve "all their problems". Engineering then has to work round it; and since the documentation for the tool will either be non-existant or untrue, the developers have to experiment at the tool to see what happens. When they get some code that works, they just LEAVE IT ALONE and get on with other things -- remember, there's no budgetted time to do this anyway, because Management has budgetted time based on the promise of the tool, not the reality.
As a result, layers of hacks accumulate. And now they work, there's even less reason to go back and refactor the stuff. So the hackiness permeates.
A tool turned up promising to support re-entrancy. It didn't in fact do that, but now the decision had been made, money paid, tool bought. Since it didn't support it, the first components written weren't written to be re-entrant either. The later versions of the tool do support it, but of course there's no time to re-write components so now the most amazing hoops are jumped through to make sure that re-entrancy is faked up where it's needed...
Environments seem to breed people who just assume ALL documentation is broken, so they don't even bother reading it, and they do ALL development by experimentation.... but that's a personnel problem.
Katie Lucas
Thursday, February 5, 2004
As for no. 15, I know I have the attention span of a goldfish, and that's why I so strongly advocate beautiful code.
If everything is full of comments and laid out neatly, it's: No attention span? No problem!
Of course, you do have to push yourself through the process. So maybe it's people who have no attention span AND are lazy bastards that fall victim to... to... um... Coffee, yeah, coffee...
Fernanda Stickpot
Thursday, February 5, 2004
What employer says... "Yeah, our code base really sucks. Could you take the next couple of months to rewrite it to your liking?"
I mostly hear... "We need you to add XXX and YYY to our existing code base. Oh what is that you say? Our current code base is 'bad code' and unextendable? Deal with it..."
GuyINCOGNITO
Thursday, February 5, 2004
As far as putting making money over writing good code goes...
If your bad code makes enough money, what's the problem?
At home I can take the time to write good code, and I do. At work we need to get things done right now in order to make our customers happy.
Some of our code was well planned and looks great. Other parts of our code were written at 4:45, and ended up terrible.
Either way, the code works and the customers pay us. That's all I care about.
I think people take this stuff too seriously. I think most of us are working on boring projects for boring companies staffed by people who also just want to get paid and go home. We're not working for NASA here.
When I want to care how good my code is, I go home and work on my PIC. When you only have 1K of RAM, you have to write good code.
Also, no more whining!
Fred
Thursday, February 5, 2004
"I think people take this stuff too seriously. I think most of us are working on boring projects for boring companies staffed by people who also just want to get paid and go home."
That's just the problem. I'd prefer such people just go home and stay home. The rest of us can get things done faster without them, and enjoy our *entire* days, rather than just the time after work.
veal
Thursday, February 5, 2004
"That's just the problem. I'd prefer such people just go home and stay home. The rest of us can get things done faster without them, and enjoy our *entire* days, rather than just the time after work. "
The industry truly needs more people like veal. Dudes revved up to put in 12 hour days integrating the great plains accounting system with the sharepoint portal server. When I was a child, I had a dream, and that dream was to become a mid-level IT systems developer for a small branch of a huge multinational corporation...
ogre from revenge of the nerds
Thursday, February 5, 2004
I didn't mean the people that also want to go home are standing around making life hard for me. I mean that they don't really care what happens, as long as things work. Therefore I don't get all gung-ho about writing their software. I just do it and go home. Thinking about it more than you have to will make you crazy.
If I were writing the software that runs a Mars rover, then I would care.
Fred
Thursday, February 5, 2004
Waz^
bob harris
Tuesday, February 10, 2004
fuck you assholes you son of bitches
bob marley
Tuesday, February 10, 2004
you all are big dimbasses and are going to hell and no i did not read any of your commits
bob marley
Tuesday, February 10, 2004
Uhh i surely think the result of hacking is good it helps us catch uhh terrorist yah & it uh is good in my decade uh we didnt have computers or hacking to stop the japenese them dam imbisuls there nuthn but trouble im going to sleep bye
bob borley
Tuesday, February 10, 2004
Im so crazy im a scottish ya u like hacking ill give ya hacking cuss here i comes tu ya ill give ya whaat ya nead ull sea
bob hummvie
Tuesday, February 10, 2004
im bob im bob yes thats me im like that dude that liked to p he wrote books well so will i ill hack his rhyming ass & say hi to me
bob bushel
Tuesday, February 10, 2004
oh shit i typed more hate mail sorry i have multipul persanalitys and get drunk a lot well either way screw you guys i'm going home .oh wait i am home
bob marley
Tuesday, February 10, 2004
fuck you bob marley i am going to assasinate your stupid probaly black ass you dumbass niger
bob cliton
Tuesday, February 10, 2004
you tell em cliton kill that fucking niger
bob herman
Tuesday, February 10, 2004
Im the president & i dont give a rats ass about the U.S ill go off like clinton leave my bitch & get me a new one ill have to buy viagra first.I have an eighth grade education but now im thinking im smarter than You cause dumb america chose me
George W. Bush
Tuesday, February 10, 2004
oh you dun it now me and the other black panthers gona kick you r ass and chop off your dick
bob marley
Tuesday, February 10, 2004
oh ya well me and my kkk friends are gona get drunk and light a cross on fire and stuff wait what
bob cliton
Tuesday, February 10, 2004
Im back again my bitch almost caught me plus dick cheney keeps bothering me to change his diaper. He stinks like shit all over all dam now what that bitch ill be back.
George W. Bush
Tuesday, February 10, 2004
 Recent Topics
Fog Creek Home
| 
