These are the roughly unedited notes from the Thursday keynote from EclipseCon: Uncle Bob Martin on Software Professionalism and the Art of saying "No"
There are lines you will not cross. We may make lots of compromises, but there are some lines you will not cross.
First, do no harm to the function of your software.
But you may introduce bugs, what about that? Doctors manage to swear this oath. Can they pull it off? No, sometimes they screw up and so do we, but it's a good target to hit. I may fail but I'll do the dilligence necessary to make sure my code works.
That means we're responsible for our imperfections. And we take responsibility when we do do harm to our software.
QA group is absurd. QA should FIND NOTHING. Why do we have a QA group? Because developers weren't doing their jobs so we had to create a whole new group to find their bugs! How did we get in a mode where we lost responsibility for our quality.
QA role should change completely, instead of being at the back of the process, have them at the front of the process, specifying what the quality criteria to be.
You do not release code until you know it works.
Manual tests are desperately expensive.
I'm not expecting that you will achieve 100%, I will demand that you achieve 100%.
People do not want us to write software that is hard to change. There is an implicit assumption that software is easy to change. It is incumbent upon us to make sure software is easy to change.
There are two values of code, one is its function and another is its structure, its value to grow and change.
"Yeah, but they won't give us time." Baloney! That is your problem, not theirs.
How do you make software that is flexible?
Design and architecture are not the only keys to flexibility. Software must be flexible. To make sure your software is flexible, you must flex it.
Nothing makes code more flexible than a suite of tests.
Professional developers are not afraid to change their code under any circumstances because they rely on their tests.
Managers say "We want these kinds of people." But that allows you the right to say 'no.'
There are a whole bunch of things you can say 'no' to. One of those is schedule.
Manager says "Wait, you can go faster if you don't write all those tests."
You say "No, you can't go faster without those tests. We go faster with those tests."
"You can go faster without design on architecture."
"You can go faster without refactoring" -- "You can go faster when you can refactor your code."
The worst thing you can say when your manager pushes on you is "Well, we'll try." There is no trying.
HOPE is the project killer. Hope keeps managers from making the decisions they need to make. Hope keeps developers from being fruitful. It is your job as a professional is to destroy hope. One way to do it is through short iterations. Measure in continually shorter cycles in order to see how much progress you can really get done.
The agile process is not about people, it's about finding out how long it takes small projects to get done. It is a HOPE destroyer.
Say No To Dirt.
Bad code got written because a bunch of bad develoeprs thought it was their job to make the most hideous mess they could make in the shortest amount of time. How that mess got made I don't know but you have to get rid of it!
There is a meme: "We have to get to market, so get the code done quickly. Keep your code as clean as possible all the time." Our mothers tried to teach us this.
The only way to go fast is to go well. Anything worth doing is worth doing well.
Say no to dropping your disciplines.
Say no to your manager, but really, say no to yourself. You're the one that you have to say no to.
You know what your discplines are when you are under the gun. And when you abandon what you do under stress are your true discplines.
Say no to overtime.
I'm not saying don't work overtime, it's good to work some overtime. But you should know your limits. But when your managers enforce overtime, you have to know your limits. You have to be the one to stop yourself.
Say no to meetings.
Managers it is your job to keep your people out of meetings. Meetings are the bane of productivity at companies.
The instant a meeting gets boring, leave. I exercise that right, and I encourage you to do so too.
Say no to dumb restrictions on your development environment.
Who is working in a place where you can't bounce a process? (no changes to a development database?) Engineers need complete control over their environment. You should have absolute control over your environment. You should have absolute control over your facilities?
What does "Saying No" mean?
You make your argument energetically. And then you work with your manager for some acceptable compromise.
No comments:
Post a Comment