Test Driven Dev
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
Clients that know about it like it because it aids in ensuring that only that which they need gets built. Its an effective armor against gold plating. It works best when you build the test stubs first and then code to satisfy their requirements. By the time you've satisfied the test, your done. So really your not spending all your time writing tests, your using the tests to guide your development and spend all your time writing the app. In your case you might have been able to trim 5k lines of code and maybe a month of coding. But.. yer mileage may vary. This statement is false.
-
i am impressed to see so much code working so well. not because this is impossible to do, but because so many people don't seem to do it (mutters darkly about trainee programmers i have had to clean up behind) so with this in mind, i am curious. is the code quality the result of a solid up front design, or of lots of "can i brake this" testing by hand as you have gone along? or do you have some other secret? :) i find the *idea* of unit tests for my code interesting, but most information i have encountered on the subject seems aimed at C#, and does not look well suited to GUI heavy C++ code, so i have never got past the vague interest stage *shrug* so i just try to be very careful when writing my code, and give it a good hammering, before sending it off to be tested, which seems to work quite well for me personally, and the general quality is very good. zen is the art of being at one with the two'ness
feline_dracoform wrote:
i am impressed to see so much code working so well.
So is my client. :->
feline_dracoform wrote:
not because this is impossible to do, but because so many people don't seem to do it (mutters darkly about trainee programmers i have had to clean up behind)
I'm not a trainee programmer, I'm a senior consultant. No, I'm not boasting or implying that titles matter, I'm just saying that you get what you pay for.
feline_dracoform wrote:
is the code quality the result of a solid up front design, or of lots of "can i brake this" testing by hand as you have gone along? or do you have some other secret?
Once again, not to boast or blow my own bubble, but I'm really good at creating software. I love it, I do it in my free time, I read about it before falling asleep, I read about it on my commute, I talk about it with strangers online, etc. There's no black magic or secret tricks, just dedication and experience. It doesn't hurt that I don't have to work with others. I designed the entire system from the ground up, I wrote all the code, I chose the design patterns to use, I chose the naming conventions, and every other detail was under my control. That's the best way to get quality software: give one (possibly two) dedicated expert the freedom to create it as he/she sees fit and then leave them alone until it's done. Throwing a crappy dev into the mix is like adding poison to the punch. :josh: My WPF Blog[^]
-
Clients that know about it like it because it aids in ensuring that only that which they need gets built. Its an effective armor against gold plating. It works best when you build the test stubs first and then code to satisfy their requirements. By the time you've satisfied the test, your done. So really your not spending all your time writing tests, your using the tests to guide your development and spend all your time writing the app. In your case you might have been able to trim 5k lines of code and maybe a month of coding. But.. yer mileage may vary. This statement is false.
Chris S Kaiser wrote:
In your case you might have been able to trim 5k lines of code and maybe a month of coding.
I doubt my consulting firm would like that very much! :-D :josh: My WPF Blog[^]
-
Roger J wrote:
"you" in this case is you and your QA team and everyone else that is responsible for delivering a solid app.
For better or worse, I am the only person involved with creating this application suite. That makes testing it easier, in some ways, because when a feature is added I have a good idea of what was effected.
Roger J wrote:
the wole point of unittesting is to spend _less_ time writing test than you would spend manually testing it by clicking around in the application.
No matter how many unit tests I were to write, I still would need to test it by clicking around. I wouldn't feel comfortable just creating a build, checking that there are no testing failures, and then shipping the assemblies off to be packaged. Empirical testing, in my opinion, can never be replaced with automation. I suppose that if I were leading a dev team I'd require people to create unit tests, especially if I didn't know the team members. But for an app that I build without anyone else interfering, I still can't see it as a justifiable way to spend time. That's just me, I suppose. :josh: My WPF Blog[^]
Yeah, I don't think its meant to replace Empirical testing but to enhance it. Its your first line of defense when refactoring. As said before you can use it to at least ensure that nothing major was broken. But I find that it helps to start with it. Plugging it in after the fact could be monumentous. This statement is false.
-
Josh Smith wrote:
So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit.
That's because you did it backwards. You're supposed to write the tests first. Naturally, after writing 35K lines of code over 8 months, you don't want to go back to writing tests now. And quite frankly, I bet your architecture doesn't even readily support a TDD methodology, as TDD, while not driving architecture, is at least an influential consideration. And BTW, that's not meant as a criticism of your architecture, but just the reality, that writing tests after the fact can require changes to your code. And frankly, if you're code is working as well as you say, I wouldn't change it just to accomodate a TDD. Also, there's nothing wrong with good old fashioned asserts and null tests. Frankly, even with TDD, these should still be in your code, as part of TDD is to test how your code handles failures, not just the successes. (Would that we could test people the same way!) On the other hand, if your client wants to move forward with your BOF, there's some good business sense in writing tests now, so that as the BOF is enhanced, modified, whatever, your client has a suite of regression tests they can perform. And that's the real business case for TDD, IMO. (ah, BOF, TDD, IMO, BTW, where's my propeller beanie?) Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-- modified at 13:31 Sunday 16th July, 2006
Marc Clifton wrote:
is to test how your code handles failures, not just the successes. (Would that we could test people the same way!)
Don't know what your spiritualism extends to, but its been said that when your in partnership with the spiritual tutors, your life gets harder not easier, as we are measured by how we handle failure and not success. That ol' divine providence... myth? ;) Although I prefer the Coyote reference of the trickster keeping us on our spiritual toes. This statement is false.
-
Chris S Kaiser wrote:
In your case you might have been able to trim 5k lines of code and maybe a month of coding.
I doubt my consulting firm would like that very much! :-D :josh: My WPF Blog[^]
Dunno.. I'm finding that there never is any end to the work needed. I'm starting to like the idea of building something and then selling it off for someone else to maintain. As agile as I try to remain, enhancement requests are always causing me to refactor under the gun.. although that's more of an artificial deadline thing. This statement is false.
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
I suspect that like a lot of things in the programming world it's just another way to manage large projects with large numbers of programmers. A lot of theories and practices you hear about for development just don't scale down at all to small shops with smaller teams or projects. Take it and anything else with a grain of salt and steal only the bits that help and drop the rest.
-
I suspect that like a lot of things in the programming world it's just another way to manage large projects with large numbers of programmers. A lot of theories and practices you hear about for development just don't scale down at all to small shops with smaller teams or projects. Take it and anything else with a grain of salt and steal only the bits that help and drop the rest.
John Cardinal wrote:
I suspect that like a lot of things in the programming world it's just another way to manage large projects with large numbers of programmers.
Ok, now we're getting somewhere! That makes a lot of sense to me. For a project which is large enough to require a large team, I can see how unit tests would provide accountability.
John Cardinal wrote:
Take it and anything else with a grain of salt and steal only the bits that help and drop the rest.
Yeah, good advice. :-D :josh: My WPF Blog[^]
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
Your attitude reflects mine a few months ago. I was very skeptical, especially with all the surrounding hype. But after using it now for several months, whilst getting exposed to mock objects and the like, I've found TDD is awesome for several reasons. For one, you get more stable, more easily refactor-able code. This is because you are certain each function behaves exactly how you expect it to behave. Another great that is you can fix a bug, then write a test for it to ensure the bug never happens again. Moreover, you can write a feature or bug fix, then test it completely from code. Forget the whole code/run/restart dance; you can test a feature completely by running tests. This not only saves time (you don't have to wait for your big rich client to startup, connect to your server, then try out the new functionality), but it also is more comprehensive, covering things that would be difficult to test, or so rare occurring that one would rarely run into it in the real world. Tests can be run quickly and can be run on any developer's machine, thus, if you refactor your code, you can run the test to tell you if you broke anything during the refactor. Finally, tests are like live documentation; a test like ShouldReturnNonNullStringOnValidInput is self-explanatory. If a developer comes along and modifies that function, your test will point it out immediately. My only complaint about TDD is it requires more time invested into writing code. However, the time invested is actually time saved, as you don't have as many bugs and you don't have to do that code/debug/rerun drudgery.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Goof around music jam with my brothers (with video) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Your attitude reflects mine a few months ago. I was very skeptical, especially with all the surrounding hype. But after using it now for several months, whilst getting exposed to mock objects and the like, I've found TDD is awesome for several reasons. For one, you get more stable, more easily refactor-able code. This is because you are certain each function behaves exactly how you expect it to behave. Another great that is you can fix a bug, then write a test for it to ensure the bug never happens again. Moreover, you can write a feature or bug fix, then test it completely from code. Forget the whole code/run/restart dance; you can test a feature completely by running tests. This not only saves time (you don't have to wait for your big rich client to startup, connect to your server, then try out the new functionality), but it also is more comprehensive, covering things that would be difficult to test, or so rare occurring that one would rarely run into it in the real world. Tests can be run quickly and can be run on any developer's machine, thus, if you refactor your code, you can run the test to tell you if you broke anything during the refactor. Finally, tests are like live documentation; a test like ShouldReturnNonNullStringOnValidInput is self-explanatory. If a developer comes along and modifies that function, your test will point it out immediately. My only complaint about TDD is it requires more time invested into writing code. However, the time invested is actually time saved, as you don't have as many bugs and you don't have to do that code/debug/rerun drudgery.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Goof around music jam with my brothers (with video) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
This not only saves time (you don't have to wait for your big rich client to startup, connect to your server, then try out the new functionality), but it also is more comprehensive, covering things that would be difficult to test, or so rare occurring that one would rarely run into it in the real world.
this comment strikes me, since a lot of my programming work can be described as a thick client. i read a small amount about TDD for a program that connects to a database, and was left with the impression that you had to setup a fake database for the tests, etc. i just have no "world view" of how to approach TDD *shrug* from your experience, or if anyone else has any experience, let me explain one area of code i develop and maintain. we have data files (flat files, complex format) and i have a set of code to render these data files as HTML, to show the user. there is a specification, with pages of rules, describing how and when data must be placed into the HTML X| its a rather nasty specification to work with. the rendering code is nice and modular, but complex. most of the bits are very simple (insert a bold word) but a few are complex (parse the data file into logical blocks depending on its format). given the input is a record from a database and the output is a piece of HTML i get the feeling TDD is going to be a set of input files and a set of "valid outputs", and basically a long list of "input A gives output B" tests, which will be a pile of work to setup. *wonders* as i am thinking this through i may be making progress in understanding this. would a TDD approach be a series of input files, ranging from very basic to very complex, so you start by satisfying the very basic tests first, slowly working up to the complex tests? or am i still missing the core idea at work here? zen is the art of being at one with the two'ness
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
You never see the real advantage to it until you get a feature request that requires you to take the app appart and put it together again to do it right. With a large suite of tests you can be much more fearless doing things the right way even though they are high risk rather then slapping in a couple of hacks to get through this round of updates. It also defends against the ravages of time. If you have to make a change a year from now after you've been using xyz control library and the latest and greatest development techniques. The test library saves you from inadvertently breaking everything you've forgotten about in the meantime. [edit] Another advantage is coverage. When I worked at Dell, the only way we could get in the sub-thousand ASP errors per day were to write brutal automated tests that randomly clicked arond the site while entering random data in all the forms. All all that to get in the 0.0x% error rate. When you serve millions of pages a day, you get several one in a million events a day. [/edit]
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-- modified at 15:46 Sunday 16th July, 2006
-
feline_dracoform wrote:
i am impressed to see so much code working so well.
So is my client. :->
feline_dracoform wrote:
not because this is impossible to do, but because so many people don't seem to do it (mutters darkly about trainee programmers i have had to clean up behind)
I'm not a trainee programmer, I'm a senior consultant. No, I'm not boasting or implying that titles matter, I'm just saying that you get what you pay for.
feline_dracoform wrote:
is the code quality the result of a solid up front design, or of lots of "can i brake this" testing by hand as you have gone along? or do you have some other secret?
Once again, not to boast or blow my own bubble, but I'm really good at creating software. I love it, I do it in my free time, I read about it before falling asleep, I read about it on my commute, I talk about it with strangers online, etc. There's no black magic or secret tricks, just dedication and experience. It doesn't hurt that I don't have to work with others. I designed the entire system from the ground up, I wrote all the code, I chose the design patterns to use, I chose the naming conventions, and every other detail was under my control. That's the best way to get quality software: give one (possibly two) dedicated expert the freedom to create it as he/she sees fit and then leave them alone until it's done. Throwing a crappy dev into the mix is like adding poison to the punch. :josh: My WPF Blog[^]
Josh Smith wrote:
It doesn't hurt that I don't have to work with others. I designed the entire system from the ground up, I wrote all the code, I chose the design patterns to use, I chose the naming conventions, and every other detail was under my control. That's the best way to get quality software: give one (possibly two) dedicated expert the freedom to create it as he/she sees fit and then leave them alone until it's done. Throwing a crappy dev into the mix is like adding poison to the punch.
I'm doing that on a BOF application for a client of mine, and, as much as I wish I could disagree, I can't. I'm really glad I'm the only architect on this project and the only developer. If I were to add another developer, I would probably spend all my time looking over his shoulder to make sure he/she does things right (right being defined as "my kind of right"). Conversely, I've been involved in other projects where I am ashamed to even have my name associated with the project as the code is so gawdawful. And nowadays, it seems my name carries some weight, so it's all the more important that I'm careful as to how I implicitly end up endorsing someone else's fiasco. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
I suppose that I would need to see a well designed test suite to be convinced that it proffers advantages above and beyond asserts and null checks. I've never worked in a TDD environment before, so I've never seen the benefits first hand.
Marc Clifton wrote:
On the other hand, if your client wants to move forward with your BOF, there's some good business sense in writing tests now, so that as the BOF is enhanced, modified, whatever, your client has a suite of regression tests they can perform.
Eek! Don't give them any ideas!! :~
Marc Clifton wrote:
(ah, BOF, TDD, IMO, BTW, where's my propeller beanie?)
:laugh: WMPB? (Where's my propeller beanie?) YPYPBNTYLSOPP! (You put your propeller beanie next to your lifetime supply of pocket protectors!) :josh: My WPF Blog[^]
Josh Smith wrote:
I suppose that I would need to see a well designed test suite to be convinced that it proffers advantages above and beyond asserts and null checks.
Well, some advice, if I may. Decouple the need for a "well designed test suite" from the advantages of TDD. Also, don't buy into TDD whole hog--it needs to meet your requirements, budget, timeframe, it needs to be part of the planning for the product lifecycle. Not being happy with nUnit, I wrote my own test framework. Am I happy with it? Mostly, but there's a few little nits that unfortunately would require pretty much a complete rewrite, argh (let me tell you about ApplicationDomain and marshalling across app domain boundaries and serializable classes one day). From my own experiences, I can tell you there is great pleasure in making a change to, say, my persistence service to add automatic client synchronization, and knowing when I'm done that I can rerun my unit tests to verify that all the other functionality is still working. I will say one thing though--I still can't write the test first. I have to write at least stubs for the actual code and then write the tests. It's because I do a lot of architecting when writing the code itself, as, ironically, I haven't found any decent code architecture/design tools--tools that don't hinder the creative process. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
Marc Clifton wrote:
is to test how your code handles failures, not just the successes. (Would that we could test people the same way!)
Don't know what your spiritualism extends to, but its been said that when your in partnership with the spiritual tutors, your life gets harder not easier, as we are measured by how we handle failure and not success. That ol' divine providence... myth? ;) Although I prefer the Coyote reference of the trickster keeping us on our spiritual toes. This statement is false.
Chris S Kaiser wrote:
but its been said that when your in partnership with the spiritual tutors, your life gets harder not easier, as we are measured by how we handle failure and not success.
Aye, I've heard that before. You bring up a good point, but I've discovered that "hard" is pretty relative. When I think my life is getting hard, I remember my best friend who's son died when he was 9. I think about farmers in Africa that are just trying to eek by an existence amid the ravishes of warlords. Etc. So, I just can't feel that, compartively speaking, my life has ever been hard. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
Chris S Kaiser wrote:
but its been said that when your in partnership with the spiritual tutors, your life gets harder not easier, as we are measured by how we handle failure and not success.
Aye, I've heard that before. You bring up a good point, but I've discovered that "hard" is pretty relative. When I think my life is getting hard, I remember my best friend who's son died when he was 9. I think about farmers in Africa that are just trying to eek by an existence amid the ravishes of warlords. Etc. So, I just can't feel that, compartively speaking, my life has ever been hard. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
Marc Clifton wrote:
When I think my life is getting hard, I remember
Absolutely. When in college I used to take different math classes for fun. Mostly because they covered cool subjects like permutations, set theory and the like, well my lab partner was this guy who had brain surgery when he was younger, major brain surgery. Part of his skull was missing. And when hanging out with him, trying to measure the volume of a fountain, people would walk up and ask how he was doin, and he always said "Good". At that point he made it so at best I could only say "Not bad" cause it was never as bad as the struggle he faced. He's still one of my role models. This statement is false.
-
Josh Smith wrote:
It doesn't hurt that I don't have to work with others. I designed the entire system from the ground up, I wrote all the code, I chose the design patterns to use, I chose the naming conventions, and every other detail was under my control. That's the best way to get quality software: give one (possibly two) dedicated expert the freedom to create it as he/she sees fit and then leave them alone until it's done. Throwing a crappy dev into the mix is like adding poison to the punch.
I'm doing that on a BOF application for a client of mine, and, as much as I wish I could disagree, I can't. I'm really glad I'm the only architect on this project and the only developer. If I were to add another developer, I would probably spend all my time looking over his shoulder to make sure he/she does things right (right being defined as "my kind of right"). Conversely, I've been involved in other projects where I am ashamed to even have my name associated with the project as the code is so gawdawful. And nowadays, it seems my name carries some weight, so it's all the more important that I'm careful as to how I implicitly end up endorsing someone else's fiasco. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
I'm on a team with a few people here, but I'm the only one working on the mobile side. So I get that experience there, while on the server side its shared, and while I won't bash the server code, its not bad, I really enjoy being the sole developer on the mobile side. Part of it for me is that I get to think how "I" think vs the standardized group think. Since we spend most of our time in the code, I wonder how many people realize that its a matter of thinking. That was vague, but this is the reason I can't code in VB. An old version is in VB that I still have to maintain, someone else's code, but everytime I work in it my brain hurts, not because I'm prejudice, but because I just can't think that way. This statement is false.
-
Judah Himango wrote:
This not only saves time (you don't have to wait for your big rich client to startup, connect to your server, then try out the new functionality), but it also is more comprehensive, covering things that would be difficult to test, or so rare occurring that one would rarely run into it in the real world.
this comment strikes me, since a lot of my programming work can be described as a thick client. i read a small amount about TDD for a program that connects to a database, and was left with the impression that you had to setup a fake database for the tests, etc. i just have no "world view" of how to approach TDD *shrug* from your experience, or if anyone else has any experience, let me explain one area of code i develop and maintain. we have data files (flat files, complex format) and i have a set of code to render these data files as HTML, to show the user. there is a specification, with pages of rules, describing how and when data must be placed into the HTML X| its a rather nasty specification to work with. the rendering code is nice and modular, but complex. most of the bits are very simple (insert a bold word) but a few are complex (parse the data file into logical blocks depending on its format). given the input is a record from a database and the output is a piece of HTML i get the feeling TDD is going to be a set of input files and a set of "valid outputs", and basically a long list of "input A gives output B" tests, which will be a pile of work to setup. *wonders* as i am thinking this through i may be making progress in understanding this. would a TDD approach be a series of input files, ranging from very basic to very complex, so you start by satisfying the very basic tests first, slowly working up to the complex tests? or am i still missing the core idea at work here? zen is the art of being at one with the two'ness
Sounds like a multiple staged approach. I would start with a test to parse the input files validating their format. So that part just validates the formatting. If you have an app that generates these files, you could plug the test in to validate the output before saving. Then I'd have another test that would validate the output given an input file that passed the first test but is feature complete. And really this is where it gets vague and complex. This might not be able to have an automated result. As it might be a visual test requiring the human involved with looking at how it appeals to the eye. I don't think its supposed to be the panacea of dev. But an excellent supplement and sanity check. This statement is false.
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
I support your skepticism. The core of TDD is writing tests before you write the code. I've found this tends to lead to inferior code since the resulting code tends to be written to be easily tested, not to solve the problem of the larger system. The bigger problem with TDD is that it assumes you have correctly anticipated all the requirements of the code and how the code will actually be used. Having said this, do be careful not to throw the baby out with the bath water. While I reject the core notion of TDD--writing tests first--automated testing for modules is a VERY good practice. This allows you to add tests as failure modes become known and a good way to regress any changes you make to the code. (One problem in TDD is finding that a fundamental code change will greatly improve the application but will render the tests invalid as written. This WILL happen often. The temptation is to compromise the code so the tests either don't have to be rewritten or the rewrite is minimal. If you aren't careful, you end up creating an application that passes all the tests, but doesn't solve the customer's problem. As a developer, we may proclaim this simply won't happen, but tell that to the people writing your paychecks.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
I'm on a team with a few people here, but I'm the only one working on the mobile side. So I get that experience there, while on the server side its shared, and while I won't bash the server code, its not bad, I really enjoy being the sole developer on the mobile side. Part of it for me is that I get to think how "I" think vs the standardized group think. Since we spend most of our time in the code, I wonder how many people realize that its a matter of thinking. That was vague, but this is the reason I can't code in VB. An old version is in VB that I still have to maintain, someone else's code, but everytime I work in it my brain hurts, not because I'm prejudice, but because I just can't think that way. This statement is false.
Chris S Kaiser wrote:
but because I just can't think that way.
Exactly, and not just related to VB. I'm working with a client that is putting together a huge client-server system, and I simply cannot get my head around his architecture, nor his code. I don't think my brain is wired right. I understand things for about a day, and then they leak out and I'm left asking "why are we doing it this way?" and "what does this code do again?". Of course, it doesn't help that there are zero design documents, zero architectural diagrams (except the ones I've done), zero unit tests, and about .01% of the code is commented (and the reason it's even .01% is because of the code comments that I religiously put into the parts I've contributed in this latest round of rewrites). So maybe that explains why my brain feels like a sieve when I look at the code. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
Chris S Kaiser wrote:
but because I just can't think that way.
Exactly, and not just related to VB. I'm working with a client that is putting together a huge client-server system, and I simply cannot get my head around his architecture, nor his code. I don't think my brain is wired right. I understand things for about a day, and then they leak out and I'm left asking "why are we doing it this way?" and "what does this code do again?". Of course, it doesn't help that there are zero design documents, zero architectural diagrams (except the ones I've done), zero unit tests, and about .01% of the code is commented (and the reason it's even .01% is because of the code comments that I religiously put into the parts I've contributed in this latest round of rewrites). So maybe that explains why my brain feels like a sieve when I look at the code. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
That's funny. There are no comments in this code. Mostly because the manager doesn't believe in them. The theory was: If you don't understand the code from reading it you probably don't belong here. ;) Which has its merits I guess. But looking at some of my code, I'm left wondering WTF I was thinking. I've commented some of it, but not enough. The other one I love alot is lacking requirements. The date gets set, and then the requirements get filled in. And they wonder why that impacts the release date. I'm being too nitpicky when I ask for complete definitions. But then I share in the heat when its late. Heh heh.. I better duck, my manager might be reading. ;) Funny, I'm on contract but he's still my boss. The lacking comments is my fault though, I just blasted through the code to get it released, and now I'm paying for it. This statement is false.