Quote:Original post by theOcelot
Quote:Original post by Decrius
I always Code Like Hell. Don't try this at home.
Quote:Original quote from the article you linked.
I am not proposing a code-like-hell methodology.
Umm... I guess you're aware that you're violating the advice of that article?
Not to be negative but that guy at coding horror has some amusing stuff but also some really sketchy ideas.
Especially when I hear a lot about guys throwing out large masses of code, or redesigning many times, or thinking they are done then the last 10% takes as long as the first 90%. I never simply get these issues. Obviously when this happens you are 'designing' things that you don't understand how to do if that's the case, or which depend on something else. You are going too low level without any assurance any of your ideas work, and getting into more and more elaborate things you may not need at all. Like when people simply grab a ton of design patterns and shove them in the design before knowing if they are even necessary.
It's easy in programming to add in layers of metaness, and really a good programmer's job is to figure out how to figure out things, not actually figure them out as is the case for an engineer or a sysadmin. When you get into process you step outside of that even more and for management or architecting you step outside even further, and the problem here is you are building up a bigger and bigger house of cards with a lot of assumptions about how things will work and you are not even necessarily describing what the thing actually DOES, far and away the important piece to communicate to your coworkers.
If you have 15 programmers it's just unavoidable to lose a lot to mere process overhead, and you likely have to answer to someone to say how much time something will take or what the cost will be. There's some variance for projects and data is generally important to business projects but it is a mechanical process to figure this out and should not be seen as designing your actual program. For other projects really just defining behavior is the important part. There's a million ways to answer 'design' questions like how to organize data but generally you will settle into a template for certain types of projects anyway and you can only establish the merits of various approachs by actually doing them and refining them over time.
But ultimately, yes, code like hell. That doesn't mean code blindly but you will quickly realize as you code "hey I need this. And that. And that.", all kinds of stuff that even a barebones prototype will have to address. Not to mention 99.999999999% of people who might use the software but are not programmers are totally incapable of seeing what's wrong with something (at least in their eyes) just by descriptions or even mockup screens that don't do anything. But of course reality comes in to play for things like legal contracts, or process requirements of customers or needing to have some good CYA on the estimate of the project.
