These notes are based on a talk presented by Robert C. Marting at Elapse Technologies on Septemeber 24 2014
Are we professionals
A professional takes his job seriously They have pride in their work Knows what they need to do, don’t compromise on what they need to do Are we professionals?
We need to be
There is software everywhere - handhelds, electronics, everything… Are there software in cars? Does software control important things like brakes, engine, throttal
How many times a day do you put your life on an if statement written by a 22 year old in the morning…
Example of failure is Night Capital Example of Barclays Bank and zero balances
At some point something very very bad will happen, and it will be some software guys fault. We don’t want to be that software guy…
Your company, our company depends on its life for the software that it writes…
It is easy to forget to behave professionally
We have not grown up in an industry who has considered itself seriously…
We haven’t taken ourselves seriously
We have some expectations
These are the types of behaviours that would be expected from a normal set of professionals…
We will not ship shit
Under no circumstances will we ship shit. We will not do it. This is a fundamental responsibility of a professional The period of shipping fecal matter has ended
You will always be ready
We will always be ready
- ready to deploy
- ready to execute
- ready…
Don’t hear…
- The realse isn’t ready
- QA is burining it in
- Module still needs to be put back together
If you can pull it off every day, pull it off every day If you can pull it off every hour, pull it off every hour Find a way to be ready to deploy every time
Add features in such a way that if you need to deploy tomorrow it’s OK
I understand not having all the features done, I don’t understand not being able to deploy
Figure out how to be constantly ready Figure out how to keep the software running all the time without defects
If it gets checked in, it’s ready to deploy. Period.
Stable productivity
Don’t start out fast and then slow down Some people start a project very fast, and then a year later go very slowly If you can deliver features at a given rate, the rate should be constant.
Maybe the way to do this is by not making a mess. Bad code slows us down, so here an idea - no more bad code. Keep the code clean and we can go fast all the time.
Inexpensive Adaptability
When the customer changes their mind, expect this to be alright. I expect as professional for people to have identified parts of the system that change against the parts of the system that don’t change When the things that change, change, it is a simple matter of changing it When the delivery mechanism changes, expect it to be easy to make the change.
Continous improvement
We should never have a response that the whole system needs to be redesigne
We should continously imrpove the system
The system should not get out of date
Constantly keep the system up to date, clean, improved
Nobody should slide down the relaing hill into irrelevance
Keep everything continously clean and continously working
The boy scout rule… Leave the campground cleaner than you found it
Fearless competance
Over the years, people have become afraid to make changes - afraid of their code, afraid of what happen if they touch a line of code If you touch it, you might brake it, and if you break it, it might become yours - that fear is not professional, and is not expected There are disciplines such a TDD that may help this happen
Extreme quality
I expect extreme quality Go home every night, look in the mirror and say, wow I did a good job I really earned my pay today, I earned double my pay Always feel that you have done the best job you could The code you have written is as clean as possible, estimates as accurate as possible, designs as good as possible Behave like professionals
The company is asking you to take risks outside the ability to cover them, however you should look at it and think there needs to be something I should do about that, and probably the only thing you can do is never let that happen again
QA will find nothing
I expect QA to find nothing Sometimes mistakes happens, things are overlooked, but these should be extreme exceptions QA should wonder why they are there It’s our job to make them worried about it When QA has done nothing, they have done their job
We cover for each other
We are a team, team members cover for each other In a sports team, each person can play other peoples position, in case someone gets hurt All of us should be able to cover for each other It will mean you will have to learn someone else’s job, be familiar with it, somehow work with other people on a regular basis If a person disapear, the team should be able to still make progress without waiting for them to come back
Honest estimates
What is the most honest estimate, the most honest estimate is “I don’t know” If you have some idea of how long it will take, be very careful on how you say it. If you say, I think it will take 3 weeks, you have lied. What you are trying to say is, it might take between 1-10 weeks. Give estimates in ranges, make the uncertainty visible. The most likely answer is 3 weeks, but there is a good chance it might take 10 weeks, and a moderate chance it could be 1 week.
The worst thing you can say is “I will try” What are you going to do differently because you will “try” Try means, go away.
Automation
The expectation is automation Humans should not be doing a repetetive job Automate test scripts, build scripts, deployment scripts, and everything else Everything should happen at a click of a button Do not tolerate manual behavior
Continous Aggressive Learning
A programmer is constantly learning Constantly ahead of the curve You need to be ahead of the curve I’m not going to pay you to learn, you should do it at home
Mentoring
You need to teach, take the new people coming in and teach them every day Show people how things work Bring out the next batch of programmers who will not make the mistakes that we have made
