Moving this discussion over from the
"What turns you off about DF" thread...
Err, I think you read too much into what I said and maybe took it too far. I delete lots of code (most of it the other people in the office that are doing it wrong 
) but I tend to dislike creating my own throw away code unless it's necessary. There's a difference between re-factoring, and just simply throwing up code to make something work for the boss. I tend to plan out my program and create it "the old fashioned way" instead of the new "agile development" ways where you barf up something then go back and fix all it's problems. Yes, barf coding leads to faster demonstrable items, but it also leads to some of the particularly fun sites like DailyWTF. Have I done it... Yes. Have I hated to do it? Yes. Have I learned from it? Yes.
Well, first of all it sounds to me like we agree a lot more than we disagree. I don't advocate "barf coding," and I think a lot of people do use an oversimplified understanding of "agile" practices to justify all manner of hideousness. However, not all throwaway code is created equal. Sometimes, for example, a fake implementation serves a role in integration until the real component can be developed. I'm sure I don't have to preach to you about the benefits of continuous integration, exercising interfaces early and thoroughly, etc. Such benefits can easily outweigh the effort involved in stubbing out a component. Since we were originally talking about scaffolding, not shantytowns, I think the metaphor is more apt to what I'm talking about than to what you describe.
But jumping the gun by saying I NEVER do something because I said I hated to do something just is taking what I said WAY too seriously.
Yeah, but you'll note that I didn't say that.
Like Fortress development, I tend to plan out a layout scheme (and sometimes graph it out on paper) before I get started instead of some of the other folks who just throw rooms wherever it suits them. I'll have a small tunnel running off into somewhere that looks totally random, but in reality it was an already planned location for a housing tower and I just wasn't ready to dig out the stuff around it yet... but I needed the rooms. So I quickly dig out a single tunnel that follows predetermined halls counting the squares I need to get into that tower structure and slowly start working my way there. It means less starting my fortresses over "aka deleting code" because I didn't think about the problem ahead of time. I know how many rooms I need. I know that I'm going to put them in stacks. I know I need to keep them X units from workshops and that needs to be around resources...
DF is a lot less forgiving of a design environment than a programming language. There's effectively no iteration involved in the design of a single fortress, because you can't un-dig (unless you like ugly mixtures of constructed walls and natural/engraved stone.
Personally, I generally pause the game at embark and plan out a big chunk of mining. I lay out all the mining designations, but I make cuts selectively to portion off areas I don't want to dig right away. That lets me figure out a design where everything fits together, much like your method.
Starting over a fortress is not a good analogy for deleting code, by the way, because deleting code rarely means burning your project to the ground and starting over on a new problem.
if you go in like you state you just get a cluster of garbage layouts. Sure, you get a fort built up fast, but it's not very efficient.
Um, like I state? You mean using scaffolding? That doesn't at all imply what you're talking about; on the contrary, anyone who's building scaffolding has a multi-step plan they're executing. How could you call that slapdash?
It's not counterproductive unless your productivity doesn't care about quality... and I know a lot of coders that don't care about doing it right. I don't know how many times I've had to correct some of my coworkers classes that use public variables as parameters, non-thread-safe static vars that worked for their test, but caused all kinds of garbage in production data and cleaning up after them countless times... but they got commended by the boss for getting in early and decried later for the code I showed him later that caused X problem that lost the company three times their salaries worth. Yeah... I'll stick to a well planned development cycle and enjoy the commendation pointing out how they screwed up by coding once and not throwing away because they got pulled to another project and ran out of time to go back and fix it.
Right, but temporariness and quality are different axes of variation. I agree that perhaps poor engineers should not write temporary code, because I don't trust them to get rid of it cleanly later. It's not the code that gets written and deleted later that's the problem in most projects; it's code that should be deleted but doesn't.
My issue with your approach is that there are legitimate objections to old-school development with lots of up-front design. It's rarely good to just jump in with zero design, unless you're really just making prototypes to explore ideas or do proofs-of-concept, but there is plenty of room for variation in the range above zero. The problem with too much up-front design is that you're doing it at the time when you understand the problem the least well. Every day you spend coding teaches you more about the problem you're trying to solve. Why would you want to be making decisions based on information that's months stale? Also, requirements change disgustingly often, so it's best to focus on writing flexible code that doesn't assume anything it doesn't have to, and factor well so that you can focus your time on implementing functionality that's needed the most definitely/soon.
Author
Topic: Throwaway code (Read 588 times)