{

We’re All Screw-Ups

Let’s be honest with each other.

Partner / CTO at Syndicate Theory 8 Years developing as freelancer, and as several team

leads

adrianschneider.ca@AdrianSchneider

Adrian Schneider

Most small shops or freelancers don’t think about process.

Most people (in Kelowna) don’t have experience in formal environments.

Back-end developers or server guys are the natural explorers of this topic. (“DevOps”)

Let’s talk about it.

Overview / Audience

He is a decent developer.

Bob never admits his screw ups.

Bob likely costs the company a lot of money.

Bob doesn’t like being confronted.

Does Bob work at your company?

Meet Bob

Joe is clever, and keeps an open mind.

Joe understands the benefit of automating his work.

Bob and Joe rarely see eye to eye.

and Joe

Some developers can pull several times their weight.

Others do more harm than good.

It can be very difficult for management to figure out who is who.

(There are no metrics we can use…)

Developer Skill Varies

Writing software is easy & maintaining software is hard.

Writing great software is hard, but maintaining it is much easier.

Software costs several times more to maintain than it does to write. This cost is often proportional to the quality of documentation left behind.

Doing it right the first time pays off.

Maintenance is Expensive

1. Find / Get Task

2. Do it …Test it?

3. Upload Changes Directly

“Oh shit”

4. Upload more Changes -> (repeat?)

Done

What Bad Process Looks Like

Bob tends to screw up at every step.

More steps lead to more errors.

We want to minimize the number of steps.

We want to remove extraneous decisions from his workflow.

Robots are faster and more reliable than Bob.

Bob is Error Prone

Bob Needs This:

Joe Likes This:

Systems which track and document changes to our files.

We can document groups or sets of changes together.

We can combine it with other tools to enhance our process.

Examples: SVN, Git

Source Control

All developers should use it.

Dear Technical Management,If your developers are not using source control, you are not doing your job.

Dear Technical Employees,If you are not using source control, you are not doing your job.

Who should use it?

We make mistakes. We change our minds. We don’t trust Bob.

Source control allows us to view changes, go back in time, or merge multiple copies together.

It’s a massive safety net. You may not need it, but when you do, you’ll be glad it is there.

It also allows us to hold each other accountable.

How can it help?

A ComparisonWith Source Control

Without Source Control

Versioning Files are automatically versioned

Rollback, Compare, etc.

• index.php• index.php.old• index.php.old2• index.php.archived• index.php.backup• index.php.broken

Accountability Bob broke it at 4:55pm on Friday.

Something broke recently…?!

Deployment Scriptable Manual

{Enter Process

Bob is a nice guy, but…Let’s not make him think too much.

Let’s introduce Ernie, the project manager, or boss man.

Are Joe & Bob actually working? Is his team on track?

“What’s the status of that bug that crippled us last week?”“Which one?”

(sigh)

Ernie, The Man

Joe & Bob hate being interrupted for updates, but Ernie needs them. Here are the two popular options:

Ask. Instant, but Interruptive. Email. Delayed, yet slightly interruptive.

Wouldn’t you rather Ernie check himself?

Joe & Bob Love Ernie

Team work becomes natural once we can work as a unit. Our output must be standardized…

Coding Standards/Conventions Tools Used (Issues, Knowledge Base, etc.) Development Process Testing Process Deployment Process

Ultimately, our “workflow”.

Standardization

The issue tracker is at the heart of a developer’s workflow. Similar to source control, all developers should use one.

Find one that integrates with your source control system. And your IDE… if you’re into that.

Bug/Issue Tracker

Issues can be tasks, new features, bugs, etc.“STUFF TO DO”

Centralized issue list keeps everyone on the same page.

Associate code (or changes) to specific tickets.

A starting point for a developer to begin work.

Database: easy to sort, filter, and create reports.

Issue Tracking

ComparisonWith Without

Communication

“#141”

Centralized. “In the cloud”, even.

Ernie interrupts for updates.

Bob asks, “which bug?”

Accountability Joe and Ernie:“Wow Bob is useless”

Bob: “Wait, there’s a bug?”

Professionalism

Database for past, present & future tasks.Self Documenting.

Bob:“I don’t create bugs.”

Integration With source control, IDE, deployment

All tasks are in the tracker. If they’re not, they don’t exist.

This reduces extraneous communication This gives developers & management a single place to look.

All code is in the repository. If it’s not there, it doesn't exist.

Other developers know where to find code. Until you commit it, it doesn’t exist as far as the project is

concerned.

Everything in Place

{Workflow

How do you get from A to B?

NEW - Ernie has a new task for Joe. He creates it in the bug tracker, and assigns it to Joe. Joe is automatically notified.

Basic Workflow (1 of 4)

ACCEPTED – Upon checking his task list, he sees his new task. He reads it, understands it, and accepts if. If there are any problems, he can comment on it and bring it to Ernie’s attention.

Joe codes away locally.

Whenever he commits code, he references the ticket number, which attaches the commits to the ticket automatically.

“ref #155 changed password algo”

The rest of the team can view the commits (changes) when viewing the ticket.

Basic Workflow (2 of 4)

RESOLVED – Once Joe is done working on the issue, and he has tested it locally, he can update the task as resolved.

Commit: “fixes #155 removed typo”(he could update the ticket manually, too)

The ticket is assigned to Ernie again, who can close it if he is satisfied.

Basic Workflow (3 of 4)

CLOSED – Ernie can mark it as closed once he has verified the work is complete.

Or

It can be marked as closed once it’s put into production. Pushing code to production is also a change we want to track.

Basic Workflow (4 of 4)

{Best Practices

Some random bits of advice.

We should have everything required to completely build the project.

Source Files Default Data, Changes to DB Unit Tests Documentation

That means…

No build artifacts No developer-specific files (IDE crud) No environment-specific content/files (logs, cache, etc.)

What do we Version?

You should commit in isolated units of work. More often is better than less often.

If a change requires editing three files, commit them together.

If you switch between multiple tickets, commit first.

Don’t want to commit broken code?

Make branches for new features or large changes Git has lots of other tools for this

Our commits are our documentation. Keep it clean.

When do we Commit?

Work locally and then test locally.

Test on a staging server before putting it into production.

The average developer should not need to push to production.

Document which code goes live and when.

Operations needs to make testing and deployment simple and fast.

About Environments

These tools are to hold each other accountable.

Do not use them to micro-manage people.

Do not force people to commit on fixed intervals.

Use them to make the process smoother. Less uncertainty.

Management…

It’s not always your boss, or the developer you are watching that can break things. Consider…

Technology / Glitches Other Developers (subcontractors?) The Client

They may not even come right away. However, having proper documentation , you can easily defend yourself.

Threats…

Well-defined process reduce uncertainty and redundancy from our tasks.

Source control gives us a massive safety net that we do need. It also gives us accountability.

Using tools effectively can make you significantly more productive.

Summary