Mark Pearl

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.


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


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

blog comments powered by Disqus

Want to get my personal insights on what I learn as I learn it? Subscribe now!