...unless your sloppy code hides a security bug which, when exploited, costs them money.
When we work hard to write elegant code, we discover the patterns that allow us to write better code when crunch time comes.
Your code may be elegant, but mine works
11–20 of 174 posts
Re: Your code may be elegant, but mine works
#12> If the client needs a Christmas promotion, and you > deliver the best product in the history of promotions -- > on December 29th -- it's worthless. Isn't the point to set a deadline that allows the product to be built to a certain standard of quality? If you only ever have time to write untested copy-paste "code that fucking works" then you don't have a problem with your development approach ... unless you're convi…
Just reminded me of a story about the designer Peter Saville (from the film 24 Hour Party People)
Tony Wilson: "You've got the posters? It's the fucking gig!"
Peter Saville: "Yeah, I know - it just took ages to get the right yellow."
Tony Wilson: "The gig's over."
Peter Saville: "I know."
Tony Wilson: "It looks fucking great actually - yeah, really nice. It's beautiful - but useless. And as William Morris once said: "Nothing useless can be truly beautiful."'
Re: Your code may be elegant, but mine works
#13The code is elegant AND it works, so it'll beat the one that just works every time.
This kind of post is always the same, but any decent developer knows when you have to just "get it done" and when you should take time to make it the right way. And of course, that dirty code will be refactored later on.
Always using the "f*ing works" strategy just means you're mediocre at writing code. Either because you led the management team to think anything can magically be built in a "hackathon" or you just don't care about what you build.
Re: Your code may be elegant, but mine works
#14His code may be elegant, yours may f*ing work, but mine works without the profanity.
Re: Your code may be elegant, but mine works
#15Re: Your code may be elegant, but mine works
#16... and as expected, it's always the manager, not coding types that state this so aggressively. I know the servers are beefy at OmniTI, so I suspect there might be a code problem related to handling the load.
If I see sloppy code, or have to write sloppy code, I move to another company, and will continue to do so. So how's that employee turnover rate (hint, use the internet archive and check the about us page)?
Re: Your code may be elegant, but mine works
#17The difficulty of changing code is directly proportional to the amount of code that has to be changed. This is almost tautological.
So, 6 months ago, perhaps the least difficult thing to do to make a new spreadsheet report was to copy and paste the first one and change a few bits of the query. Repeat 10 times. Management is happy, look how many reports we churned out. Maybe you thought about making a generalized reporting system or something, but your boss was pressuring you. "It's so simple, just do the simplest thing. Just make it work."
But now that we have a dozen reports, that asshat in management says he wants graphs on these reports, even though he told us 6 months ago "no way in hell" would he ever want graphs on these reports, now he's telling us we're "such typical programmers, no fucking common sense." Suddenly the change isn't so easy, we have to touch a metric shit tonne of lines of code.
Technically speaking, it's going to be fewer lines of code to change to copy-pasta the graphs into all of the existing reports. But we only need to get burnt once to realize that this management douchebag is going to try to burn us again in the future. So, we figure it's only a small percentage more difficult to completely rewrite the reporting system from scratch. And then it will be easy to add new features in the future.
He is correct in one sense, it should have been done that way in the first place, but that is the nature of getting burnt, you put your trust into someone who was untrustworthy. The management asshole put pressure on you to get the "simple" reports out fast, slow-rolled you on the additional reports, then doesn't want to hear "excuses" or "details" or anything other than "the job is done."
So that's where so-called "over engineering" comes from. It's not. It's self preservation. And at your next job, you'll remember it should have always been that way, and you dig your heels in on every design decision. And suddenly you're "that guy" who is always saying "we tried that at our last job and it didn't work."
I have a policy that I always say I can get the job done. I never tell the client that they can't have what they want. But I never compromise on quality. What you want takes a certain amount of effort to create, make sure it's good, and make sure it doesn't impede our future efforts. Working in this way ensures I establish a consistent expectation for how the work will go and the quality of the work over the lifetime of the project. Consequentially, I get the work done on time and everyone is happy with it, almost always.
Re: Your code may be elegant, but mine works
#18Earlier quoted context omitted.
Or distinctly inelegant and unable to scale to f *ing working for HN.
Hay! Don’t be a hater. The most important thing is he delivered it on time. Who cares if you can’t use it? That’s secondary.
I guess he moved pretty fast and broke some stuff.
/cheap shot, it's probably just a wordpress site without caching plugin or whatever the usual magic is to make it work.
Re: Your code may be elegant, but mine works
#19Reducing software development practices down to these cute catchphrases is a bit disingenuous. If you're writing throwaway code for a client with loose constraints and a tight deadline you'll write code differently then you would when you expect to maintain a long term relationship with a client who expects a high degree of correctness. I'm tired of these trite articles espousing some cute mantra holds as if it's som…
Exactly. Specially with the chosen title.
Almost all similar articles I read, are used as some kind of self justification to writing bad code and leaving it there forever.
If you believe the software will fail (won't ever be changed/grow), do whatever you want with it. If you think it'll succeed, stack too many dirty hacks together and you're gonna pay for it later with tons of interest.
Main problem is, too many times this goes "unnoticed", people just take longer and longer to do the same things, but people stay oblivious to the real causes of that technical debt.
Re: Your code may be elegant, but mine works
#20The code is elegant AND it works, so it'll beat the one that just works every time. This kind of post is always the same, but any decent developer knows when you have to just "get it done" and when you should take time to make it the right way. And of course, that dirty code will be refactored later on. Always using the "f *ing works" strategy just means you're mediocre at writing code. Either because you led the man…
> And of course, that dirty code will be refactored later on.
In my experience, the same product development lifecycles and business priorities that led to the dirty code in the first place will cause it to live forever. Code that works doesn't tend to get refactored unless it needs to be revisited for some other business purpose.