Comment Re:Nothing beats... (Score 1) 444
..."bit-rot" doesn't really happen if you don't change anything.
If we don't do anything to our part of software, it doesn't rot. Unfortunately, our part of the software is not the only part of the software. How could we prevent the rotting of other parts effecting our part? What an interesting question, isn't it?
Speak for yourself.
I do. So, could you please tell, what is a software. Is it only the code? The compiled or the source? Or does it include something else? Why?
Remember those "analysis" and "requirements gathering" steps?
Are you suggesting the dumbed-out-boehm-waterfall model? I didn't think so. Even the original Royce's waterfall model had at least two iterations: first to try out (with waterfall model) how to implement the software, then to use waterfall to implement the software.
Design is always trial and error, or at least based on it. I just would like it to be "trial and error by implementing" not "trial and error by stickmen and ellipses." In other words, "design with concrete facts, not with vague drawings." One of my former colleagues had this admirable habit of never to suggest any design proposals without first trying them out.
You said really strong and wise advices ("if you don't understand the problem domain" etc.), and I couldn't agree more. All I'm saying is: implement first to find the way to understand the problem domain. This implementation just has to be thrown away, otherwise it comes to be the product, a badly designed product.
Why reinvent the wheel?
Look around. Are we using just one web-browser? Just one word processor? Just one operating system? Playing just one FPS or racing game? Reinventing the wheel seems to profitable, money talks. I don't like it either.
Change the first part to "for well understood problem domains" and I'll agree.
Yes, I should've said so. Thanks for the correction.
And read some Petroski.
Thanks, I will. You might like trying Feyerabend.
If we don't do anything to our part of software, it doesn't rot. Unfortunately, our part of the software is not the only part of the software. How could we prevent the rotting of other parts effecting our part? What an interesting question, isn't it?
Speak for yourself.
I do. So, could you please tell, what is a software. Is it only the code? The compiled or the source? Or does it include something else? Why?
Remember those "analysis" and "requirements gathering" steps?
Are you suggesting the dumbed-out-boehm-waterfall model? I didn't think so. Even the original Royce's waterfall model had at least two iterations: first to try out (with waterfall model) how to implement the software, then to use waterfall to implement the software.
Design is always trial and error, or at least based on it. I just would like it to be "trial and error by implementing" not "trial and error by stickmen and ellipses." In other words, "design with concrete facts, not with vague drawings." One of my former colleagues had this admirable habit of never to suggest any design proposals without first trying them out.
You said really strong and wise advices ("if you don't understand the problem domain" etc.), and I couldn't agree more. All I'm saying is: implement first to find the way to understand the problem domain. This implementation just has to be thrown away, otherwise it comes to be the product, a badly designed product.
Why reinvent the wheel?
Look around. Are we using just one web-browser? Just one word processor? Just one operating system? Playing just one FPS or racing game? Reinventing the wheel seems to profitable, money talks. I don't like it either.
Change the first part to "for well understood problem domains" and I'll agree.
Yes, I should've said so. Thanks for the correction.
And read some Petroski.
Thanks, I will. You might like trying Feyerabend.
