RichardOnRails wrote: > Hi Marnen, > >> have too much pride in my work to sell them a clunker that will be in >> the shop all the time. I'm not willing to compromise on quality -- and >> test-first development helps ensure that I can develop high-quality > > What you're claiming is that to not employ formal testing is > tantamount to shoddy work.
No; my point is a bit subtler than that. Let's go back to the car analogy. If you want to make sure that you're not building your car with substandard materials, you have to have some way of knowing that the materials you're using are within spec. How do you do that? You establish guidelines for the materials you will use (purity, breaking strength, whatever), and then you assay the materials to make sure they meet these guidelines. The assay is crucial: without it, you'd never be able to guarantee that the materials were within spec. You might get lucky and have the purest, strongest material in the world, but then again, you might have garbage -- and without the assay, you wouldn't know till it broke at 60 mph. And so it is with software. You might have the best code in the world, but without tests, how can you be sure of that? More importantly, without tests, how can you refactor reliably? > But the proof is in the pudding. Actually, you mean "the proof of the pudding is in the eating". :) > I never > would have survived as an independent computer consultant for decades > if potential clients suspected I did shoddy work. Just because your clients don't suspect it doesn't mean it isn't happening. > They always new > what my previous engagements had been and I'm sure checked to their > heart's content. Which tells them very little. If they understood enough to check over your previous projects really thoroughly, then they wouldn't need to be hiring you in the first place, because they could do the job themselves! > > And I was always constrained to use the client's chosen programming > language though I'd often wished I could use something better. > Introducing foreign ideas like writing tests while no visible repairs > or new functionality emerged would not fly. I don't buy it. The client is hiring the developer to produce the best possible software within the constraints. "No tests" is never a reasonable constraint. > Finally, the fact that I > didn't use formal testing regimes does not mean that I did no testing! > Good. >> That doesn't impress me without knowing more about the organization and >> his role there. Too many big organizations don't understand the 'Net. > > So you think a guy with the title Internet Architect in a national > organization in constant computer communication with in multiple > cities in almost every state in the U.S. might just be boob when it > comes to the Internet? In a word, quite possibly. I mean no disrespect to your son by saying this; it's simply a sad fact that title inflation is rampant in this field. > Do you think he might also be a jerk even if > he graduated college summa cum laude from an accredited university > might be unsophisticated. Yes. I've met people whom that would describe. > And that he's developing through me an > expense tracking system for two private schools he owns and operates > might not have a clue as to the impact of code I/m writing. > Yes. If he knew the impact of the code that intimately, he wouldn't need you to write it, now would he? Generally speaking, our field is one where formal credentials are too easily obtained by the undeserving. I've seen post after post on forums pointing out that the English major who fell into programming because he loves it is often a better developer than the guy with the shiny CS degree. > I work on this for two reasons. (1) To help my son reduce the burden > of managing a small enterprise.and (2) after toying with Ruby and > Rails for years in retirement, to finally dig in to these technologies > and hang out my shingle again offering web development services for > small business. Those are both excellent goals, and I wish you best of luck in both of them. That's in fact why I've been harping on the importance of doing things right. > >> Waiiiiiiiit...so it's up to your client to tell you whether you're >> hacking? WTF? How is he even in a position to know? > > YES. And I hope you think I've answered the second question. He's > written a ton of Java and WSDL and Unix and Linux and Windows and > plenty of other stuff I know nothing about, like those packages for > administering large organizations. But the development is your responsibility, not his. Unless something got lost in the translation, it sounds like you're trying to foist off onto your client concerns that are properly your responsibility. > >> > But I'm a version of the earlier >> > you. So, like you, I get to Agile-land. But, like St. Augustine, >> > I'll give up sin, but not right now :-) >> >> Are you sure you want to model your behavior on a fairly hypocritical >> line? :) > > Shucks, Marnen. I thought that last line was the best one in my > entire reply. I agree. :) > > BTW, as I mentioned to Colin, I've been playing around with unit- > testing today. Yes, I saw. Good luck! > I feel like writing a generator to populate views when > columns are added/renamed/dropped from a DB table. It annoys my that > there's no tool to do that. You can use the scaffold generator, or (for a more sophisticated version of the same thing) ActiveScaffold. But in most cases, this task is beyond the scope of a generator: it needs actual human thought and is not that susceptible to automation. > > Best wishes as always, > Richard Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
