Your code may work, but only on your dev environment when the wind is blowing from the east.
Your code may be elegant, but mine works
81–90 of 174 posts
Re: Your code may be elegant, but mine works
#82If the project is late, it's not done. Period.
Bullshit. Most deadlines in software engineering are fake. There are some that aren't, but they are exceptions, not a rule. If you're writing all your code as if every deadline is the Judgment Day, you're doing software engineering wrong and not making the right trade-offs.
The unfortunate reality is that there are some engineers who will gladly deliver software 5% faster and 600% worse just because it makes them look good with the management. They justify their behavior by all kinds of BS, but in the end it hurts the industry, their clients and the society at large.
(There is another breed of engineers that will deliver software 600% slower and 200% worse because of overcomplicated design. Yeah, that's also a pathology. But it's not like you have to choose only between these two pathologies.)
Re: Your code may be elegant, but mine works
#83Reducing 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…
>Reducing software development practices down to these cute catchphrases is a bit disingenuous.
Its a bit like Scientology, but without the crazy.
Oh no, wait .. there's plenty of crazy.
Re: Your code may be elegant, but mine works
#84I must share an anecdote. A recent project was assigned to me which was outsourced to a consulting company, they ditched the project after 80% completion. I was required to do the rest. I went through the code and it was horrible. They had no concept of DRY principle - little code pieces were copy-pasted everywhere. There was no naming convention, variables were randomly names, in some places they made use of ORM, other places had raw SQL queries used with mysql_query() calls. It was a gigantic mess. If the code would've been organised properly, the rest 20% would've taken me 10 days, now I'm not sure how long it's going to take. Even though the code works and whatever they did is functional, but its light years away from maintainable. "Mine works" isn't always a good solution.
Re: Your code may be elegant, but mine works
#85Another point to add to this: the majority of what we do is ephemeral. I battled with this idea for a long time (even being 100% adverse to what this article says at one point), but ultimately I learned to accept the fact that code on the web is temporary and ultimately subject to change.
A quote by Ethan Marcotte (the guy behind responsive web design) sums it up nicely for me: "Designing for the web is like building sand sculptures."
Yes, there are certain situations where you should double-down on engineering, but it's wise to see if what you're building will even be around in a few months. Not to mention, a lot of the code I write is obsolete by the time it ships (either by virtue of my skills improving or the framework/language I'm using upgrading). A guy I have in my Skype list has the most foretelling status: "you're writing legacy code."
Re: Your code may be elegant, but mine works
#86Without seeing examples of what they consider "fucking done" and "elegant" it's kind of a moot argument. Maybe they're already writing decent code, or maybe their working on short term projects that just need to be finished and not long standing products that require years of maintenance and ease of upkeep at the added cost of complexity.
Re: Your code may be elegant, but mine works
#87They have a CEO, a CAO and a VP of business development but nowhere on their about us page does it list a CTO or ANY senior level "engineer". And this is why their company doesn't value doing development right.
Re: Your code may be elegant, but mine works
#88The higher order bit remains writing high quality code under pressure that works. High quality encompasses well tested, adherence to abstractions, maintainable and readable.
Re: Your code may be elegant, but mine works
#89I used to work at OmniTI. The real irony of this article is that it was written by a guy who's (in)famous for his indecipherable Perl one-liners. I think that's about all that needs to be said.
> I think that's about all that needs to be said. Yeah, and that's like a perfect definition for "ad hominem" argument.
No, actually it's not. This isn't ignoring the issue at hand and just attacking the author's character, it's attacking the authors authority on a subject matter.
Re: Your code may be elegant, but mine works
#90Earlier quoted context omitted.
It's also worth noting that he's talking about things like "if your client needs a Christmas promotion and you deliver on Dec 29". This sounds about right. But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I am currently developing and maintaining a s…
> But if you're in a time-sensitive situation and your code will only be used for a brief period of time, your business needs are probably very different than a code-and-maintain-forever situation (e.g. a SaaS offering). I think this captures the central problem in our current software development state of affairs. Because as developers we are stuck with primitive tools that make doing even trivial stuff time consumi…
I don't know that sophisticated spreadsheets are trivial to create. I've seen way too many weird, buggy and outright broken spreadsheets to believe that.
I agree with you we should strive to make trivial things simple to write, and I also agree many programming tools fail at that, but I don't agree the software we write (in general) qualifies as trivial. Even some spreadsheets don't qualify. People writing them often make a horrible mess of it, unless they truly are simple spreadsheets.