3 ms·

Thank you for that. I've got the idea now. In these projects, are you responsible for the maintence and later code changes? Or are these projects one time deli

Thank you for that. I've got the idea now. In these projects, are you responsible for the maintence and later code changes? Or are these projects one time deliveries and someone else handles things from then on? Also, if you don't mind my asking, how many years of experience did you have in working in the IT industry when first trying your hand at TDD?

eesmith 9y ago
I don't think that's an informative question, because the answer is "yes." Which cases? For software I sell, I am responsible. For software I write as a contractor/consultant, it depends on the contract. After all, I'm not going to maintain it forever, for free. For the two week contract I said I would fix things for 3 months [0], if it was something I should have caught during development. I don't recall them asking for any changes, but like I said, we did a code review at the end to get the two local people up to speed with what it does, and they are good people. The project used a combination of technologies which they hadn't used before. The "yet another project" was a series of work orders across 18 months, where I did two major rewrites to handle new capabilities. Someone local was also reviewing the code, doing validation, and making a few patches. Nearly all of it was me, including maintence and code changes. I've done several projects for that company for about 5 years. Again, I'll fix errors that should have been caught during development. On that last project, which finished in February or so, there was a bug report two weeks ago which I investigated and suggested two possible fixes. They chose one and implemented it themselves. I started programming in 1983 and got my first full-time job in the IT industry in 1995. I didn't try TDD until around 2007 or so. Our local programming user's group does code katas. The organizer is an Agile/XP/TDD facilitator and testing advocate, so I've also learned and had practice that way. Also, she was the project lead for a project where I was involved as a contractor, so when we pair programmed [1] we did it as TDD. [0] Their standard contract said 2 years, which I said was extreme for a two week contract, but if they wanted that then I would adjust my rates accordingly. We settled on 3 months. [1] This wasn't often. I mostly worked on a back-end server component, while she worked on front-end and middleware.
- lancerkind 9y ago
  Some software languages or platforms are easier to do TDD in than say proprietary computing "appliances" in proprietary languages. You've mentioned Python, which is a pretty flexible language and conducive to doing TDD. Do you do most of your project work in Python? You mentioned getting bug fix requests. How many times over the year do requests like this interrupt your other project work? On average, how much of your effort does servicing such requests (research, meet over them, plan a fix, then do the agreed upon fix and test the agreed upon fix, deploy the fix) take? Hours, days,...?
  - eesmith 9y ago
    I'm tired of this conversation. I don't see the point of your questions, and I think I've explained my "confession" quite well enough. I rarely get bug reports concerning the software I delivered. The fixes almost always take only a few hours.

eesmith 9y ago

I don't think that's an informative question, because the answer is "yes." Which cases? For software I sell, I am responsible. For software I write as a contractor/consultant, it depends on the contract. After all, I'm not going to maintain it forever, for free. For the two week contract I said I would fix things for 3 months [0], if it was something I should have caught during development. I don't recall them asking for any changes, but like I said, we did a code review at the end to get the two local people up to speed with what it does, and they are good people. The project used a combination of technologies which they hadn't used before. The "yet another project" was a series of work orders across 18 months, where I did two major rewrites to handle new capabilities. Someone local was also reviewing the code, doing validation, and making a few patches. Nearly all of it was me, including maintence and code changes. I've done several projects for that company for about 5 years. Again, I'll fix errors that should have been caught during development. On that last project, which finished in February or so, there was a bug report two weeks ago which I investigated and suggested two possible fixes. They chose one and implemented it themselves. I started programming in 1983 and got my first full-time job in the IT industry in 1995. I didn't try TDD until around 2007 or so. Our local programming user's group does code katas. The organizer is an Agile/XP/TDD facilitator and testing advocate, so I've also learned and had practice that way. Also, she was the project lead for a project where I was involved as a contractor, so when we pair programmed [1] we did it as TDD. [0] Their standard contract said 2 years, which I said was extreme for a two week contract, but if they wanted that then I would adjust my rates accordingly. We settled on 3 months. [1] This wasn't often. I mostly worked on a back-end server component, while she worked on front-end and middleware.

lancerkind 9y ago
Some software languages or platforms are easier to do TDD in than say proprietary computing "appliances" in proprietary languages. You've mentioned Python, which is a pretty flexible language and conducive to doing TDD. Do you do most of your project work in Python? You mentioned getting bug fix requests. How many times over the year do requests like this interrupt your other project work? On average, how much of your effort does servicing such requests (research, meet over them, plan a fix, then do the agreed upon fix and test the agreed upon fix, deploy the fix) take? Hours, days,...?
- eesmith 9y ago
  I'm tired of this conversation. I don't see the point of your questions, and I think I've explained my "confession" quite well enough. I rarely get bug reports concerning the software I delivered. The fixes almost always take only a few hours.