3 ms·

I like the article in general, however sometimes i think that an ideal solution in terms of design sometimes can't exist, I mean a program mostly grows after us

by merb 10y ago

I like the article in general, however sometimes i think that an ideal solution in terms of design sometimes can't exist, I mean a program mostly grows after usage and gets many changes over time. sometimes something which was quite good, is now rusty and bad. I mean at the moment I'm actually changing my code that was simple at first, but over time more and more things were added and it started to complex. The thing I'm doing right now is getting rid of the complexity to add another future. Well mostly I think a big problem is that many people actually think about the design too much, since the design of a program will eventuelly be changed anyway. What worked for me was design something that works in most cases and grow that path or throw it away if it sucks. btw. I love what antirez did and does for the community of programmers. I always use a redis client to teach people more about network programming in java. It's a extremly simple, but still powerful command set/protocol. I hope he can keep up his work.

doubleplusgood 10y ago
One of things that come with experience is the ability to foresee the potential changes and ensure that, when possible (preferably during the initial spec phase) the solution is extensible/flexible enough to accommodate the most likely changes. For a simple example, if you're asked to implement something like a blog, you would naturally be prepared to be asked for authentication, authorization, contact us forms, commenting, etc. If you're aware that there's a high probability of such a change request in the early phases (but not NOW), then that anticipation will usually result in better code.
- merb 10y ago
  That's exactly what I think does not work. You can't see the future. Of course a simple project want to have that, but a big project is unpredictable. You should make it flexible by having a great test infrastructure to move forward fast, but you should try to create something that doesn't exist yet. Maybe it is needed, maybe not, it's just too unpredictable to write code for something that doesn't exist in the customers head.
  - doubleplusgood 10y ago
    I didn't mean "implement features before they're requested". What I meant was that designing flexibly will allow you to iterate better, and given some experience, you will probably be able to "predict" the next feature req or 2.

by merb 10y ago

doubleplusgood 10y ago

One of things that come with experience is the ability to foresee the potential changes and ensure that, when possible (preferably during the initial spec phase) the solution is extensible/flexible enough to accommodate the most likely changes. For a simple example, if you're asked to implement something like a blog, you would naturally be prepared to be asked for authentication, authorization, contact us forms, commenting, etc. If you're aware that there's a high probability of such a change request in the early phases (but not NOW), then that anticipation will usually result in better code.

merb 10y ago
That's exactly what I think does not work. You can't see the future. Of course a simple project want to have that, but a big project is unpredictable. You should make it flexible by having a great test infrastructure to move forward fast, but you should try to create something that doesn't exist yet. Maybe it is needed, maybe not, it's just too unpredictable to write code for something that doesn't exist in the customers head.
- doubleplusgood 10y ago
  I didn't mean "implement features before they're requested". What I meant was that designing flexibly will allow you to iterate better, and given some experience, you will probably be able to "predict" the next feature req or 2.