Are you listening? I’m about to give away the secret to to all of this this Lean/Agile/Software Craftsmanship fuss. The secret is… DISCIPLINE.
“The time is always right to do what is right” — Martin Luther King, Jr.
Assuming we know what to do, and I know a lot of you reading this do, we should always just say no to shortcuts. Delivery pressure is a real thing, but if you’re estimating a piece of work, estimate what it’ll take to do the right thing. If real Object-Oriented Programming is new to you, it’s going to take you a whole lot longer to get something done. If the language is new to you, it’s going to take you a lot longer to get something done.
Sometimes we take embarrassing and unprofessional shortcuts like:
- Getting out of TDD mode.
- Rolling shoddy spike code into production.
- Using an older, more familiar but less quality recipe to a common coding task.
The best way I know of to keep discipline up is pair programming. Some would say pairing is the way because two heads are better than one. I say it’s a great practice because it creates a healthy peer pressure.
Learning and discipline are the two halves of continuous improvement. In short: live what you learn, act on your new knowledge and skill.
@Pragmatist “you end up with … two programmers with the output of one maybe”
How do you measure output? Number of characters typed? Lines of code? Tasks completed within a day?
If you take a long view of output, pairing produces AT LEAST as much output. By long view, I mean something like features implemented in a release, including number of bugs found.
I admit some tasks don’t benefit from pairing. But if your team is spending most of its time writing code so simple that it doesn’t benefit from pairing, you need to invest some time improving your tools.
Pairing is all about working smarter not harder, quality over quantity, etc.
Pair-Programming? your kidding right? what you end up with is two programmers with the output of one maybe. The only pressure you need peer or otherwise is it works or you get fired…
It is good practice to collaborate or bounce ideas off of fellow programmers, but to try to get two or more programmers to agree on a single way to perform a particular task results in two things:
1. Exercise in futility.
2. The individual with the weaker personality conceding to doing the task the other guy/gal’s way…
The name of the game is “Get It Done”…
There is always the right way, the wrong way, and the way that gets it to market first and you get paid for; and allows your company to remain in business and you to continue to receive a pay check…
Great words. Tell ‘em my boss please! Yes, I think the main problem of this (I read about that almost every day on different locations) is a boss who don’t understand this.
I couldn’t agree more, very well said
“The time is always right to do what is right” — Martin Luther King, Jr.
It is my goal to use that quote for something good tomorrow. Thanks for the post.
Halelujah brother, preach on.