Fast, good and cheap. Pick two. The author's projects require more fast and cheap than good to be successful. Other projects will have different requirements.
Your code may be elegant, but mine works
101–110 of 174 posts
Re: Your code may be elegant, but mine works
#102Reducing 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…
A while back I tried to add some clarity to the discussion.
Re: Your code may be elegant, but mine works
#103If 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% faste…
Exactly. The author cites a Christmas promotion as an example. Yes, those types of projects exist, but in my experience, they're a tiny minority. Almost every deadline I've ever faced was set artificially. The developers estimate how long the project will take, they negotiate with management, and one or more deadlines are established. Often these deadlines are missed (not due to the programmers, BTW), and there's no actual harm to the company or the project.
In my view, the reasons for such artificial deadlines are a) so all involved parties can plan their schedules, and b) because an undefined timeline has a tendency to become an infinite timeline. Rarely do these two needs imply dire consequences for a missed deadline (provided it's not missed by an excessive duration).
Re: Your code may be elegant, but mine works
#104The main reason that I agree with this is that developers are, as a group, the boy who cried wolf. It's not that technical debt doesn't matter or code quality doesn't matter but so many developers complain about technical debt and code quality when their concern is irrelevant or flat-out wrong that it's difficult to distinguish a legitimate concern from complete BS. Developers very often use technical debt or doing t…
I don't know man. I have been buried under mountains of technical debt before. It's a pretty horrifying experience and makes me paranoid about writing bad code. It's kind of like how starvation makes you see food differently. Technical debt isn't a joke.
Re: Your code may be elegant, but mine works
#105Reducing 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…
The worse thing is that he's saying "you shouldn't spend extra time to do the right thing", and then tries to justify that by giving examples of people doing the wrong thing. Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.
I don't know. The whole ecosystem we live in (YC) seems to be about, "Your idea may be good, but mine exists."
Basically, the same thing as he's saying.
Re: Your code may be elegant, but mine works
#106Reducing 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…
The worse thing is that he's saying "you shouldn't spend extra time to do the right thing", and then tries to justify that by giving examples of people doing the wrong thing. Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice". That's a complete straw man.
"Nobody is calling spending weeks writing a caching layer for a 20-row database "elegant" or "best practice"
I don't disagree with your main points, but you might be surprised to hear some things that people will say and unnecessary optimizations they'll attempt...
Re: Your code may be elegant, but mine works
#107Earlier quoted context omitted.
> 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…
This is a problem, and I've long mused over possible solutions. Every time I think about it, I come to the conclusion that the solution isn't a new approach to software engineering, a new language that blows away every paradigm, some abstraction that promises to make app development simple, or any other silver bullet. Indeed, the only "solution" I see is a solution in just the loosest sense. Namely: We continue incre…
A good tool does not need to throwaway existing frameworks or paradigms in order to deliver. I am a firm believer in using what's already proven.
>The complexity of the tools we use is a result of their great flexibility and power.
This may see like a strength but it is actually a massive weakness. Existing IDEs attempt to be all things to all people and as a result are not actually delivering the best that they could if they were more focused.
>Given that, does anyone think they can do better?
Download our software (check my profile for link) and spend some time playing with it, you might just reconsider that position :)
Or join the newsletter, we are coming out with an exciting update that is basically going to attempt to combine wordpress-like application composition within an IDE.
Re: Your code may be elegant, but mine works
#108Earlier quoted context omitted.
> 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…
haha, I am sure there are many buggy spreadsheets out there...
I didn't mean to suggest that it doesn't require knowledge and effort to put together a sophisticated spreadsheet but relative to building even the simplest web application, spreadsheets are a breeze.
Re: Your code may be elegant, but mine works
#109After 7+ years of intense coding during my work and often evenings/weekends across many languages, a few months ago I came to the conclusion
"The ability to make those decisions (of where to cut corners), often mid-project, is what separates veterans from rookies."
I don't have the kahonas to call myself a veteran but certainly, I can now relate to this. I shall be keeping this article to forward to colleagues at appropriate times in the future, along with Joel@FogCreek's article on why re-writing software with the same guys, the same skills and a simplistic - albeit optimistic - mindset is suicide for your application/service/software.
Re: Your code may be elegant, but mine works
#110Hey it's not popular here, but I agree with this sentiment. The key is knowing when and where to make sacrifices. I don't believe in technical debt. I've seen huge codebases with many lurking dragons. Those dragons solved real problems, and made the business enough money to employ engineers who are supposed to be smart enough to work through it.
Real code that "you" didn't write is messy. It takes a long time to understand the history and context of any sizeable codebase. Perhaps that legacy feature is there to serve one customer, but it's an important customer who is about to upgrade to a more comprehensive plan. Perhaps that 100 line function is the only way to really handle some arcane API without muddying up the rest of the "better designed" parts.
Code you don't write is the hardest code to maintain, whether it's elegant or not. Code solves business problems, so without understanding the business or the specific problem it's trying to solve, you are not educated enough to make a snap judgement about it's "design" or "technical debt".
I say it all the time, code is not cement. It can be changed. Good engineers find the constraints, change the parts that are hard to understand and maintain, and keep everything up and running.
There is no "right way", or magic set of patterns that are going to save you from the realities of a user facing product.