UPS is great about delivering, but you do need to pick up your packages in a timely manner.

I signed up for UPS My Choice. It’s free and it’s great. So now I get an email that looks like this:

And if I go to that tracking number, I can sign up to be notified!

Clicking on the “Notify me with Updates” I get this:

I choose “All Packages”… There are quite a few options… and you can choose E-mail or SMS Text. The most important for me is “Delivery Confirmation”… Because then I know to go down and pick up the package.

Headline: All the modern software development practices really do make significant business impact.

Disclaimer: As usual, there is not information in this series that would be considered proprietary information for C&C Reservoirs.

This is the overview and index for a series on software development practices the team I’m leading has been using for the past several years. But let me set some context.

This is called the “Unicorn Series” because several people that saw our practices said, “You’re a unicorn!” This mythical creature that is said to exist, but now one has ever really seen it. Sometimes when someone says that they mean, “I don’t believe you.” But since I was able to demonstrate these practices, it clearly meant, “Wow! People say this, but not one really does all this!” (Someone else’s words, not mine.)

The overall objective was to take a content delivery and analysis software system for C&C Reservoirs and make it easy so we could "cross the chasm" – make it easy to use and appeal to the majority of the market. The team was given the liberty to re-write the application from the ground up. Now DAKS™ IQ is fast, easy to use, and high quality.

The key results are:

Better to use: In only 15 months we transitioned 100% of our customers from the previous software to DAKS IQ.

Available: Using cloud technology the uptime for this year so far is 99.95%.

Quality: The current rate of customer reported bugs is about 1 bug per month.

Fast: The use of cloud computing to place the application near the user and other techniques leaving the impression for most that it is a desktop application rather than a web application.

I started with key customer benefits which we all know are critical for business success. But there are other business benefits that aren’t customer facing. These help with costs and lead to the benefits above:

Cloud Strategy: We don’t even own a server! We use Visual Studio Team Services (VSTS) for our source control, builds, and releases. And we use Azure for our deployments.

Continuous Deployment Builds: Each build runs all the unit tests, some web tests, and then deploys the build to a test site after every single check-in.

Mobile First: We started with a responsive application that would work on all devices from the first deployment.

Previews: We had 6 preview releases soliciting customer feedback before our first official release.

One Week Sprints: The team moves fast and is really ready to release on any day, but most certainly each week by the sprint meeting.

Technology Stack: We used the latest technologies. There are too many to mention here, but I’ll cover that in detail.

Automated Releases: When a release is kicked off all the databases are updated, each server around the globe is updated, and this is done with swapping slots to eliminate/minimize downtime.

Feature Focus: Each feature is hidden behind that feature and any modules can be created from a collection of features. This means that we can release the software with brand new features that customers don’t yet see.

No Branching: Due to the ability to construct features on the main branch and not release them there are no branches! And it has been that way for more than 2.5 years.

No Dedicated Testing Team: We do test, but various users in the company put it through the paces. Due to the extensive automated testing we don’t need a dedicated team like many software development teams.

Focus on Usability: We continually look at the usability for each feature and the consistency of the conceptual model that allows the user to easily navigate DAKS IQ.

Virtual Team: We had team members in Houston, Denver, San Francisco, Seattle, and China. Use of Visual Studio Team Services (VSTS), Skype for Business, and Slack allowed us to work together very effectively.

Security: We focused on security from the beginning. We don’t even store passwords and all content is delivered over https.

One Team: There isn’t a maintenance or bug fix team. We all work on features and what few bugs there are. The person most capable of fixing the bug works on it, which means that for the most part, the person that wrote the bug fixes the bug.

Dogfooding: We use DAKS IQ internally to capture the data for each of our fields and reservoirs.

I’ll explore many of our team practices including those mentioned that allow us to achieve these results. Let me know what you find the most useful.

After that I did a Sync with the VSTS repo and all was well. Ok… That’s a lie. This process caused some local changes so the pull didn’t work. I had to do to the command prompt and type “git checkout .” to undo all the changes (3 of them) to my local copy. Then the Sync worked.

Some key notes…

– I had already added the items I wanted to track from another machine and committed those changes to the remote (VSTS) repo.

– If this is your first machine for the project that is using git LFS then you will need to run the track command to add them. As you can see, if I run just “track”, it shows which items I’m tracking with LFS:

You can add other files by running the git lfs track command, for example:

Some day OpenLiveWriter will replace Windows Live Writer (I hope)… But for now I use the Paste As Visual Studio Code plug in, and at the time of this writing, there’s nothing like that for OpenLiveWriter.

Then, there are many posts that show this command to actually install it without having the application call out to the web for updates, which results in an error message. Here is that command (all one line):

At least by default it doesn’t seem there is a startup sound. This is GREAT!

I travelled this week and have no idea how many times I heard the Windows 7 startup sound. Why do you need a sound? The only real reason I can think of is because the startup is so slow. The user has gone on to other tasks and you need to let them know, “Hey! I’ve actually done something now.”

But Windows 10 on my Surface Pro 4 is pretty fast for booting. It’s so nice to open it up in a meeting and not have to lunge for the volume so you don’t disturb the meeting.

Stated a different way, LOTS of people this week disturbed others as they started up their devices. They respond with a sheepish and embarrassed smile, but it’s not really their fault – it’s Microsoft. Or was. But not any more.

Thank you Microsoft for realizing that just starting a device isn’t noteworthy of announcing the the entire room or airplane.

This is my first blog post being written from Open Live Writer. I suspect there are so many people to thank that I wouldn’t even know where to start.

Details

I’ve used Live Writer for years to create blog posts. When it looked like Live Writer would go away I probably tried 10 other authoring tools (too long ago to remember which ones). And each time I thought, “But Live Writer did it right. It’s easy. It meets my needs.” So I was thrilled when Microsoft agreed to allow it to become open source.

Below is an image of Windows Live Writer on one computer and Open Live Writer on the other. You can’t really tell the difference!

Of course I guess one place to start thanking is Microsoft and Microsoft employees for making the source code available and the decision to allow it to become open source. Of course, I’m sure that’s when the real work began and I see the list of contributors on the site is quite long. Thank you all!

Headline: For modern software development I’ve been working on some key metrics that seem to correlate to high quality and profitable software.

List of Metrics

Number of customer reported bugs

Automated test code coverage

Completed user stories

Code analysis warnings

Changesets per day

Regressive bugs

Number of broken builds

Profitability

There are two components to profitability – how much money you make (revenue) and how much you spend (expenses). These metrics contribute positively to both. But for the revenue I would encourage early and frequent feedback from customers through Customer Preview Programs.

Revenue

So how do these metrics improve revenue? Obviously software with few customers bugs is more attractive to users. I’ve seen software that was so buggy that customers switched to a different solution. I’ve also been on the other side where the software was of such high quality that customers bought it in large part because it “just worked”.

In addition to stability of the software, velocity helps too. You don’t want to nag your customers with daily updates, but you don’t want to wait 18 months between releases – particularly for fairly new software. High code coverage, numerous completed user stories, and changesets all contribute to higher release velocity. You can release more frequently if your test cycles are short. And there’s reason to ship more frequently if you’ve added the top priority user stories from your backlog.

Expense

On the expense side good performance on all of these metrics contributes to low expenses.

If you have few customer reported bugs you’re spending time on user stories and not bugs.

Automated test coverage reduces the testing time and prevents injection of new bugs. Or at least detects them at the earliest possible moment – before you even check in your code (if your running all your tests as you should). Automated test coverage also reduces the staffing level needed for testing. Most domain experts spend their time determining whether the features work as desired (usability and usefulness) and not looking for bugs (the software didn’t do what the user expected).

If you can complete user stories quickly, that reduces cost. That is, the cost per user story is low.

Keeping code analysis warnings at zero helps prevent bugs too.

Changesets per day usually correlates to the completion of user stories.

Regressive bugs means that the software used to work but when you implemented new functionality you broke something. Of course this takes time which increases expense of the project, just to get back to where you were.

And finally, if your build is always broken then it is hard to ship and usually prevents developers from being productive.

Targets

So these are some metrics, but what are some good targets for these? While the answer may vary based on the size of your project and development team, this gives some view of that.

Customer Reported Bugs – I’ve seen sizable projects have only 1 or 2 customer reported bugs after several years. I’ve seen at least 10 such projects. So this is not a crazy target. So your target should be zero. But a small number shouldn’t deflate you

Automated Test Coverage – Almost all of those 10 projects had greater than 95% code coverage. Obviously strive for 100%, but there are times where you just can’t test several lines.

Completed User Stories – this is much harder to set a target for. What is the size of your user stories? What is the size of your team? If you simply look at user stories you complete, then you remove one of these factors. I feel pretty good if I can complete 1-3 user stories each week. I don’t feel good if I complete 0.

Code Analysis Warnings – Zero!

Changesets per Day – The most productive and high quality code I’ve seen is usually written by developer that have 3 to 4 checkins per day. It seems that I run across 3 groups:

Developers that break code into small testable pieces that follow the SOLID principles and have 3-4 checkins each day.

Developers that have 2-3 checkins per week.

Developers that have 1 or 2 checkins per month.

I did see several developers once that would checkin code about once every 2 to 3 months – or about 4 to 6 times per year!

Now don’t “Check in just to check in”. But as you build your code base and keep it high quality, it should become easier and easier to add new functionality more frequently.

Regressive Bugs – Zero! This is usually a sign you’re missing some critical automated tests.It’s not much fun to go back and get your code to do what it used to do. The whole purpose of agile software development is to keep moving forward.

Number of Broken Builds – Zero! Now that’s harder I think than the code analysis warnings. but I hope the build is never broken for more than 1 hour. (Which of course means you keep your code lean and your build can run in less than 1 hour.) And this is much easier to accomplish if you are checking code in every few hours. The most you’ll lose if you back out a change is a few hours work.

I’d be interested if you have other metrics for high quality software development.

I put “New Horizontal Tab Group”, “Run Code Analysis on Solution” , and “Analyze Code Coverage for All Tests” on a Visual Studio Toolbar called “Quality”.

Before you check-in

The steps before checking in code should be:

Get Latest Version

Build

Run Code Analysis on Solution

Analyzed Code Coverage for All Tests

Most advice as the first two and probably the last listed, but I think all 4 are important.

To make this easier and almost automatic, I put together a tool bar so I can just press a button for two of these actions.

Now I renamed these so that they don’t take up as much room, but they are there.

Get Latest Version

You want to make sure that you have all the latest code merged in with yours before you do your check-in, so this is the first step. If you don’t do this first then you’ll need to repeat some steps again before checking in.

Build (Skip)

Ok… I actually skip this, because it happens automatically in the next two steps.

Code Analysis

I have Microsoft All Rules turned on for Code Analysis.

But even though you check the box that says “Enable Code Analysis on Build” it doesn’t seem to report these warnings. So instead, I need to run “Run Code Analysis on Solution”. Our projects have no code analysis warnings (with very few suppressions). You want to get to zero and stay there. It’s always an expensive effort to go back and get them down to zero when they start to pile up.

Code Coverage

And obviously you want to make sure all your unit tests pass. As a matter of practice I run the code coverage to see if there are big changes in that number. The current project I’m working on has about 94% code coverage. We use a `.runsettings` file to control which libraries we analyze.

Following these steps can really improve the quality of your code and reduce bugs that escape. Just using this will typically catch misspellings in your Resources.resx file. If you get too many warnings these will slip by you and make it to your customer.

I’m sure there are some good posts on how to create and edit options in a Toolbar in Visual Studio 2015.

New Horizontal Tab Group?

Why is that in the quality bar? I routinely will use that to split my view so that my unit test is in the top group while the code I’m working on is in the bottom group. I think quickly arranging things so you can see your tests and code at the same time really helps your quality.

These tools are great, and probably many of you have already found this Visual Studio 2015 extension. They really help when trying to review code changes.

The Benefit

Today I had to compare a file from two different points in time. Unfortunately, some developers had the productivity tools and others did not. As a result I had to painstakingly look at many lines where the difference might have been “this=that” rather than “this = that”.

Getting it Setup

Here are the settings that would have helped that situation… First make sure you have the tools:

Then go to the Tools –> Options… Productivity Power Tools, PowerCommands:

:

With these settings your files will be kept tidy for proper formatting as well keeping the using statements under control.

But… make sure your fellow developers don’t go changing the definition of the format. Example, if some decides they like a Tab size of 5 rather than 4, then every line in your fill will show as changed between that developer and any version others worked on. Just leaves those defaults alone!