Discussion on:
View:
Show:
... but business factors often require just that. Nevertheless, we don't want to fall into the "broken window" syndrome and just let quality go to hell. How do you deal with this when it comes to your clients?
I have been involved with non-IT projects to mobilise new businesses and the quick and dirty route tends to cost you forever after in those environments. Trying to fix the noise in the engine when the car is going down the highway at 60 miles an hour is a much harder prospect than doing te fix before you leave and knowing the fix with hold for the rest of the trip.
Always a delicate balance but foundations allow you to build a strong framework if the are soundly implemented. If the project has a short shelf life or is a known expendable you can afford to be a lot more compromising.
Always a delicate balance but foundations allow you to build a strong framework if the are soundly implemented. If the project has a short shelf life or is a known expendable you can afford to be a lot more compromising.
Leaving the documented door open to doing it later can help. Completely ignoring it doesn't.
If doing foundational work is a habit, you will get quicker at it over time. One way to handle payment for such work might be to charge a fixed price for it, while charging hourly for the rest of the project. What do you think?
Often that part is easier to predict (except on research-based projects).
With some clients, it doesn't even need to be enumerated. It's just part of the process. It depends on how "hands on" the client wants to be.
With some clients, it doesn't even need to be enumerated. It's just part of the process. It depends on how "hands on" the client wants to be.
> So, you agree to create only enough tests to prove compliance for the most common use cases and exceptions -- but document the areas not tested. I was going to add, "so someone can go back and write those tests later" -- yeah, that'll happen. However, at least you'll know what you haven't proven, for the next time you have to extend this application.
The only part of the article I find even remotely disagreeable is the notion that you save time by documenting the areas not tested. Once you have enumerated what you should have tested, the actual test-writing part is trivial, in my experience.
Have you seen testing systems like RSpec for Ruby? They call them "Behavior-Driven Development" tools, but the truth is (as far as I can see) that they're more verbose TDD tools that use terms like "Behavior" and "Specification" or "Spec" in their usage model jargon. I'm half-convinced these tools were created primarily for the purpose of getting corporate buy-in for TDD by referring to the process as "specifying" or "writing a spec" or something like that, rather than "writing tests first". In practice, the major difference between use of BDD tools and TDD tools seems to be that the comments you should have with your tests in TDD tools are mandatory string arguments to your BDD tests.
Learn a BDD tool and tell clients you're writing executable specs rather than using an xUnit tool and writing tests before you write code, if you must. It might help get buy-in to "do it right" the first time.
The only part of the article I find even remotely disagreeable is the notion that you save time by documenting the areas not tested. Once you have enumerated what you should have tested, the actual test-writing part is trivial, in my experience.
Have you seen testing systems like RSpec for Ruby? They call them "Behavior-Driven Development" tools, but the truth is (as far as I can see) that they're more verbose TDD tools that use terms like "Behavior" and "Specification" or "Spec" in their usage model jargon. I'm half-convinced these tools were created primarily for the purpose of getting corporate buy-in for TDD by referring to the process as "specifying" or "writing a spec" or something like that, rather than "writing tests first". In practice, the major difference between use of BDD tools and TDD tools seems to be that the comments you should have with your tests in TDD tools are mandatory string arguments to your BDD tests.
Learn a BDD tool and tell clients you're writing executable specs rather than using an xUnit tool and writing tests before you write code, if you must. It might help get buy-in to "do it right" the first time.
I don't do consultant work but am the only person who can code using "professional" grade languages (rest are Matlab developers, not that Matlab is necessarily "unprofessional" but in my experience most developers tend towards the science and engineering "it seems to work good enough" mindset which my coworkers follow).
Anyways my workflow: When I get spare time I use it to catch up on new technology, build up some underlying infrastructure for programming (new revision control, new unit test suite etc), and relook at things that I wish I had done better. Since a lot of my projects tend to be modest sized (2k loc, = 10 screens) I've gotten really quick at making prototypes.
So often what I do is bang off a prototype with some functionality (say pull the data into a datagrid even though it might need to be in a graphical form later) so I have something to show. I'm prepared to through it all out if necessary but often I find if I can find incremental value to give every week or so my "customers" are happy that they can use what is already done and ask me to re-prioritize features that they really want to use soon. Seems to work for me. Then again though my customers are internal so it isn't like they are trying to get a shrink wrapped package out the door by date X with all of features Y.
Anyways my workflow: When I get spare time I use it to catch up on new technology, build up some underlying infrastructure for programming (new revision control, new unit test suite etc), and relook at things that I wish I had done better. Since a lot of my projects tend to be modest sized (2k loc, = 10 screens) I've gotten really quick at making prototypes.
So often what I do is bang off a prototype with some functionality (say pull the data into a datagrid even though it might need to be in a graphical form later) so I have something to show. I'm prepared to through it all out if necessary but often I find if I can find incremental value to give every week or so my "customers" are happy that they can use what is already done and ask me to re-prioritize features that they really want to use soon. Seems to work for me. Then again though my customers are internal so it isn't like they are trying to get a shrink wrapped package out the door by date X with all of features Y.
It seems like you've independently invented a nontrivial percentage of an agile development methodology.
Also happens in a non-consulting/in-house scenario especially when rapidly developing apps for individuals, a group, or client that "needs it now". Oh sure, it's always part of the plan to go back and clean it up but as the CCR song says "Someday never comes".
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
