3 ms·

> Less code is generally going to be easier to change later. If need be you just rewrite it. That's in general an unhealthy attitude, because later might be to

> Less code is generally going to be easier to change later. If need be you just rewrite it. That's in general an unhealthy attitude, because later might be too late to rewrite it, as complexity has a way of creeping in, as simplicity requires eternal vigilance and leadership with an iron fist, something which most teams lack. You should watch the Hammock Driven Development presentation, by Rich Hickey, in which he makes a case for the value of thinking about the problem before acting. This man is in fact brilliant in how he delivers presentations, so while you're at it, watch Simple Made Easy, in which he argues that simplicity ain't easy. TL;DR - easy to write code is not necessarily simple. But simple is objective, so you know you have it when you achieve it.

coliveira 14y ago
Another reason why simple code is not always better is that in a typical project there are LOTS of simple decisions that need to be made. If you let them for later, they will become: hard to find, hard to integrate with other "simple" decisions you made, etc.
- bad_user 14y ago
  Indeed and that's because in order to tackle complexity and scale the development process, you need layering, composition and to also avoid cyclic dependencies and complecting too many things at once. The Unix philosophy, in which things should do one thing and do it well, is a good case-study of good design, with the ugly parts being the instances in which this philosophy wasn't respected (not mentioning all the wheel reinvention going on). However it's not easy to build things that do simple things, do it well and then building on top of that. You need experience, forward thinking and resources. And OOP sometimes helps, but sometimes it makes things worse. For instance it encourages a bottom-up design. But other times a top-down process for development is better - in which you start at the top by outlining/creating a domain specific language and then implement the layer below that knows how to communicate with that language, then rinse and repeat until the layers are as simple as possible and you need no more layers and the implementation works.
trhtrsh 14y ago
Hammock Driven Development is a create way to reinvent things from scratch every few users, building elegant systems that don't ever grow to solve large problems.
btilly 14y ago
That's in general an unhealthy attitude, because later might be too late to rewrite it, as complexity has a way of creeping in, as simplicity requires eternal vigilance and leadership with an iron fist, something which most teams lack. If you want to assume incompetent programmers, then I agree. If you assume competent, experienced programmers, there is constant willingness to say, "This worked here for a bit but it is time to sit down and do it right." I've had the pleasure of working with the latter. If you have that pleasure, then a willingness to find a simple solution where it makes sense pays off in spades. And it it not unhealthy. But there is a definite element of, "If you don't know what you're doing, this is a principle that can let you make horrible decisions without realizing it."

coliveira 14y ago

Another reason why simple code is not always better is that in a typical project there are LOTS of simple decisions that need to be made. If you let them for later, they will become: hard to find, hard to integrate with other "simple" decisions you made, etc.

bad_user 14y ago
Indeed and that's because in order to tackle complexity and scale the development process, you need layering, composition and to also avoid cyclic dependencies and complecting too many things at once. The Unix philosophy, in which things should do one thing and do it well, is a good case-study of good design, with the ugly parts being the instances in which this philosophy wasn't respected (not mentioning all the wheel reinvention going on). However it's not easy to build things that do simple things, do it well and then building on top of that. You need experience, forward thinking and resources. And OOP sometimes helps, but sometimes it makes things worse. For instance it encourages a bottom-up design. But other times a top-down process for development is better - in which you start at the top by outlining/creating a domain specific language and then implement the layer below that knows how to communicate with that language, then rinse and repeat until the layers are as simple as possible and you need no more layers and the implementation works.

trhtrsh 14y ago

Hammock Driven Development is a create way to reinvent things from scratch every few users, building elegant systems that don't ever grow to solve large problems.

btilly 14y ago

That's in general an unhealthy attitude, because later might be too late to rewrite it, as complexity has a way of creeping in, as simplicity requires eternal vigilance and leadership with an iron fist, something which most teams lack. If you want to assume incompetent programmers, then I agree. If you assume competent, experienced programmers, there is constant willingness to say, "This worked here for a bit but it is time to sit down and do it right." I've had the pleasure of working with the latter. If you have that pleasure, then a willingness to find a simple solution where it makes sense pays off in spades. And it it not unhealthy. But there is a definite element of, "If you don't know what you're doing, this is a principle that can let you make horrible decisions without realizing it."