Art of Programming: Learned or natural talent?
@thepedestrian lol that's awesome.. Here is the right way -- PLAN AND DON"T SWITCH LIBS :P
I don't like to plan programs. Instead, I try to rely on emergence - make lots of small, re-usable and simple systems and then combine them to create a complex system. Or at least, that's one of the habits I'm trying to teach myself anyway.
That falls down in a huge way when the project involves more than a few people over more than a few weeks.
No, it doesn't fall down at all, it works remarkably better with big projects / big teams than a "plan everything first, code later" strategy.
Last edited on
I disagree enormously, based on my own experience. My current project, lasting about 6 years and strewn across many companies in more than one country, would have been a total catastrophe without decent planning up front.
I think it will lead to more maintainable code, because each subsystem can be replaced without changing much of the rest of the system (as long as the interface remains the same).
If you don't plan too far, you have to plan for constant changes, for unknown. Code prepared for changes is better than code implementing a fixed plan. What if requirements change in the middle of the project and you find that all of your 6-year-long plan got obsolete? There were plenty of failures like that.
Last edited on
| What if requirements change in the middle of the project and you find that all of your 6-year-long plan got obsolete? |
Does happen. Generally costs the customer 5 figures per reqt in my line, which of course is an enormous generalisation, but that's what it's cost them this round. Frequently, they (sensibly) develop the requirements in timed stages, not least because it can take a couple of months to get a reqt changed.
Last edited on
Topic archived. No new replies allowed.