4 ms·

I live by a comment Joe Armstrong made on this (from Erlang and OTP in Action): "Make it work, then make it beautiful, then if you really, really have to, make

I live by a comment Joe Armstrong made on this (from Erlang and OTP in Action): "Make it work, then make it beautiful, then if you really, really have to, make it fast." (The quote continues "90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!")

mattgreenrocks 13y ago
This sentiment is why I only work in domains that value high-quality work. My definition of high-quality is something that's done well enough that it doesn't have any obvious issues, based upon the current product vision. It should be designed well enough that we can move onto subsequent requirements afterwards. My clients/employers don't have a say in the quality of the finished product they receive. (They may be angry about this, but my responsibility is to my profession first, and them second.)
robmclarty 13y ago
Great quote. I think we all understand that spaghetti code simply adds time to the next feature we want to introduce, probably creates unseen bugs, and might explode. But it's always a balance and nothing is black and white. I hear a lot of "you're wrong, do it the right way first!" but you gotta balance "the right way" with its context. Code isn't made for code's sake, it's made to do something (like a business objective, like "be able to order a book through my browser"). Businesses are trying, first and foremost, to make profit, however they need to do that. Beautiful code has nothing to do with that goal, but is sometimes a means to that end. If the code achieves the business objective it was meant to achieve, it's doing its job (however minimally). Customers don't care what the code looks like (if they look at it). They just care that it does what they need to do (like order a book). Businesses don't care what the code looks like as long as it makes profit. Secondary to the business objective is how that code fits into the greater context of the system-as-a-whole. Obviously badly written code is going to accrue technical debt, which will likely lead to cumulative delays to new features, cause things to break, etc. The extra effort involved in dealing with that debt is obviously going to cost something, which will have an affect on the primary goal of business: profit. But also delaying a feature, to "do it right the first time", that could be earning revenue, is also going to affect profit. The key is to balance it to maximize profit overall. When I do anything (code, draw, write, cook, paint, dance, whatever) I start by doing it the simple, easy, fast way; I probably fuck it up; then I iterate and try to improve upon it and refactor. Usually in getting something out there I discover new solutions that I would not have seen had I not actually made something and put it into the world where I could look at it and point to it and talk about it with other people. Being an early mover aside, I think this kind of process helps overall quality anyway. And in the meantime I've got something that's at least doing something. I think Joe Armstrong knows what he's talking about ;)
bnegreve 13y ago
> 90 percent of the time, if you make it beautiful, it will already be fast. In fact, I disagree with this. The reason is that "elegant" usually means "decoupled" whereas many optimizations actually consists in "recoupling" to take advantage of special cases or to share resources among various decoupled objects. Designing software to be fast and elegant is actually quite challenging problem. Of course, that makes it even more interesting.
- lostcolony 13y ago
  I would argue that the reason you are choosing to recouple things, is because you fall into that 10%. Most problems can and should be solved first correctly, second elegantly, and you will find at that stage it is "fast enough". It's so rare to not find that to be true, overall (i.e., some industries, such as high speed trading, there is no such thing as fast enough, but they're writing < 10% of the total amount of code being written), that yes, I'd say the quote is accurate, and the exceptions fall into that 10%. Interestingly, too, you indicate "recoupling". That is, to couple again. Meaning for you to even be in this situation, realizing what you need to do, you had to first make it elegant. Otherwise you'd be optimizing...what, exactly? You have no metric.

mattgreenrocks 13y ago

This sentiment is why I only work in domains that value high-quality work. My definition of high-quality is something that's done well enough that it doesn't have any obvious issues, based upon the current product vision. It should be designed well enough that we can move onto subsequent requirements afterwards. My clients/employers don't have a say in the quality of the finished product they receive. (They may be angry about this, but my responsibility is to my profession first, and them second.)

robmclarty 13y ago

Great quote. I think we all understand that spaghetti code simply adds time to the next feature we want to introduce, probably creates unseen bugs, and might explode. But it's always a balance and nothing is black and white. I hear a lot of "you're wrong, do it the right way first!" but you gotta balance "the right way" with its context. Code isn't made for code's sake, it's made to do something (like a business objective, like "be able to order a book through my browser"). Businesses are trying, first and foremost, to make profit, however they need to do that. Beautiful code has nothing to do with that goal, but is sometimes a means to that end. If the code achieves the business objective it was meant to achieve, it's doing its job (however minimally). Customers don't care what the code looks like (if they look at it). They just care that it does what they need to do (like order a book). Businesses don't care what the code looks like as long as it makes profit. Secondary to the business objective is how that code fits into the greater context of the system-as-a-whole. Obviously badly written code is going to accrue technical debt, which will likely lead to cumulative delays to new features, cause things to break, etc. The extra effort involved in dealing with that debt is obviously going to cost something, which will have an affect on the primary goal of business: profit. But also delaying a feature, to "do it right the first time", that could be earning revenue, is also going to affect profit. The key is to balance it to maximize profit overall. When I do anything (code, draw, write, cook, paint, dance, whatever) I start by doing it the simple, easy, fast way; I probably fuck it up; then I iterate and try to improve upon it and refactor. Usually in getting something out there I discover new solutions that I would not have seen had I not actually made something and put it into the world where I could look at it and point to it and talk about it with other people. Being an early mover aside, I think this kind of process helps overall quality anyway. And in the meantime I've got something that's at least doing something. I think Joe Armstrong knows what he's talking about ;)

bnegreve 13y ago

> 90 percent of the time, if you make it beautiful, it will already be fast. In fact, I disagree with this. The reason is that "elegant" usually means "decoupled" whereas many optimizations actually consists in "recoupling" to take advantage of special cases or to share resources among various decoupled objects. Designing software to be fast and elegant is actually quite challenging problem. Of course, that makes it even more interesting.

lostcolony 13y ago
I would argue that the reason you are choosing to recouple things, is because you fall into that 10%. Most problems can and should be solved first correctly, second elegantly, and you will find at that stage it is "fast enough". It's so rare to not find that to be true, overall (i.e., some industries, such as high speed trading, there is no such thing as fast enough, but they're writing < 10% of the total amount of code being written), that yes, I'd say the quote is accurate, and the exceptions fall into that 10%. Interestingly, too, you indicate "recoupling". That is, to couple again. Meaning for you to even be in this situation, realizing what you need to do, you had to first make it elegant. Otherwise you'd be optimizing...what, exactly? You have no metric.