Anyway, I stumbled on this Quote on the C2 Wki:
What really matters?If I had my way these four points would be prominently displayed in every IT Department out there.
Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters?
1. Coding. At the end of the day, if the program doesn't run and make money for the client, you haven't done anything.
2. Testing. You have to know when you're done. The tests tell you this. If you're smart, you'll write them first so you'll know the instant you're done. Otherwise, you're stuck thinking you maybe might be done, but knowing you're probably not, but you're not sure how close you are.
3. Listening. You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You probably won't know this yourself, so you have to get good at listening to clients - users, managers, and business people.
4. Designing. You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise, you'll sink under the weight of your own guesses.
Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.
-- KentBeck, author of ExtremeProgrammingExplained
3 comments:
Very nicely put. There's nothing more to say.
Looking at this again, the real crucial point is in the phrase 'Software is too damned hard to spend time on things that don't matter.'
I just don't think people get this. It's so easy to write a simple piece of code - its childs play - literally. The problem is that as soon as you start tackling business problems, you're dealing with users/customers that sometimes don't know what they want and developers that often don't how to provide value to their customers.
Not to mention the technology challenges. I remember a book I had some years ago, think it was called 'Exceptional C++' or something like that. At the time, I had been a user of C++ for some 5 years and it shocked me when I realized how simple it is to make many mistakes just on a single line of code. The book used simple examples to highlight that each line could potentially be hiding 5-10 errors - and you had to look hard for those errors.
Throw this in the mix with the (in my opinion) far greater people issues, and its a tough business to be in.
The book used simple examples to highlight that each line could potentially be hiding 5-10 errors - and you had to look hard for those errors.
At my latest client I got pulled into a code review. The code was full of procedural smells. The project manager who knows a thing about OO programming was telling the "coders" what responsibilities each object should have and where to place code. He had a picture in his head of what the design should be.
I was less sure of what should be, but I could spot the smells. Some of the smells came from the design patterns the project manager and the architect had told the coders they should use.
The upshot is that programming is too complex to be done by wrote. Small steps with feedback is the only way I know to get it right. If the coders had better acceptance criteria for the feature and if they had produced the code test driven, and if they code recognise code smells, then they would have been in a position to arrive at a clean, concrete design that met the requirements and was bug free.
None of us knew what the code should be. It is just too complex to work out all at once in your head. The project manager had half and idea, but even this wasn't the full picture. Out of the people in the review, I was the only one wanting to listen to the code so that I could hear what the design wanted to be.
Everyone else thought they knew, and everyone was wrong. Knowing without listening is just too difficult, yet we try!
Like you say each line of code contains a bunch of information pointing out things that can trip you up. To pick up on the signals you need to listen to the code.
Post a Comment