How we saved $1,000,000 for Microsoft with this one, small change

British Cycling Team - 2012 Olympics

Everyday when I am doing some small bug fixes or minor improvements I am thinking about the British Cycling team. They dominated 2012 Olympics thanks to marginal improvements. Such as cleaning hands properly, taking their own pillows when traveling or sleeping in the right position. All of these small things put together resulted in 7 out of 10 track cycling gold medals.

It turns out that the same strategy might work in software development. Especially if you work on large project.

1 million dollar improvement

In Azure Portal we have hundreds of developers working on one codebase. We are using MSBuild to perform builds. With default options, MSBuild was printing out to console a lot of logs that weren’t very useful. When you are building project, you are usually interested in errors. It turned out that changing verbosity of output speed up builds from a few seconds to a few minutes depending on the project that is being built and type of the build (incremental / rebuild all).

Taking into account that there is at least 100 developers working everyday on the Azure Portal (in fact there is much more, but not everybody is working on the Portal full time), and assuming that everybody is performing at least 20 builds per day (savings up to 30 seconds per build), and 4-5 full project builds (savings around 1-2 minutes), every developer can save around 20 minutes everyday!

This gives us:

100 developers x 20 minutes x 240 days working days per year = 480,000 minutes = 8,000 hours

Assuming ~$150/hr  it give us total savings: 8000*$150 = $1,200,000

Incremental changes over years

When I am looking back, I am impressed how much the Azure Portal have changed over last two years. This is portal in 2014:

Azure Portal in 2014

This is portal in 2017:

Azure Portal in 2016

We haven’t done any breakthrough changes overnight. I have never had a feeling that one day resulted in some significant difference. It was 1 step at the time, one small bug fix one day, one tiny part of new feature another day.

Small improvements every day, everywhere…

This applies not only to large scale project. Think about Open Source. Even when you are doing documentation improvements for ASP.NET docs, you can save time for hundreds of developers. You are not saving particular company’s money, but you are saving our (developers) money and what’s even more important, time that can be invested somewhere else.

Another great example of small incremental improvements is John-David Dalton. Creator of lodash. He is contributing code on github every(!) day for a few years now. This is his github contributions chart:

John-David Dalton contributions

No white squares. Some of his daily commits are tiny, some are small. By being consistent every day, over years he was able to create one of the most popular JavaScript library.

What small improvement can you do in your project? Think about it, and remember that best ideas are born when you are away from your computer!


Lean Startup

The Lean Startup (Eric Ries)

If you are building a product that is not yet released you should read this book. If you are building a product that is already released you should also read this book. If you are working on some overnight idea this is a must read! Why? In all cases it will help you to plan features, use data-driven approach for making decisions, and avoid waisting time by doing work that is not needed.

Eric Ries describes – on example of his own startup – how his team wasted weeks and months of development work, by working on features that turned out to be not needed nor wanted by customers. To avoid such pitfall, he is proposing different approach: create simplest possible prototype, release it and wait for users’ feedback.

Lean startup is not only for startups. It is for everyone working on some product. From 1 person to international corporation. Eric gives great advice on how to evolve products and how to maximize your ROI (Return of Investment). He emphasize the importance of ability to reacting to feedback fast, not focusing too much on vanity metrics, but focusing on long term vision instead.

This book goes to my favorite books list!

If you haven’t read it yet, I strongly encourage you to do so. If you did, share your thoughts in comments!


Ignite Australia 2017

Microsoft Ignite Australia 2017

This month I had a pleasure to speak at Microsoft Ignite conference in Australia.

My talks

I updated my talk about the Azure Portal with more performance tips & tricks, and one of the most important thing I learned while working with the Azure Portal Team: the Data Driven Approach for making decisions and improving product.

I got very positive outcome during and after my session:

Azure Portal talk recommendation

 

Azure Portal - performance tricks

 

Azure Portal - Future Stack

 

I also updated my TypeScript talk with yarn (faster and better npm), and webpack (module bundler that can also compile TypeScript to JavaScript, minify it, optimize it and much more).

 

After my talks I’ve been interviewed by Duncan Hunter on Azure Portal and Building Large Scale Web Apps with TypeScript:

Recommended sessions

I personally attended, and watched later (after the conference), a few good talks. From what I’ve seen I would strongly recommend (in addition to my sessions of course):

The Technical Debt Prevention Clinic (Richard Banks) – great talk on distinguishing technical debt from bad code, and strategies to avoid bad code
Microservices, Docker, .NET, Windows, Linux, Azure. Oh, My! (Richard Banks) – awesome intro to Docker+Azure (if you haven’t check Docker yet)
Applied Azure: Building a Large Scale Real World Application on a Coffee Budget (Troy Hunt) – nice overview of different Azure’s offerings (did you know that New Relic is free with Azure App Service?)
Ten Things Every Expert Xamarin Developer Should Know (Glenn Stephens, Kym Phillpotts) – 10 good to know things if you are building apps with Xamarin
Building Azure Connected Mobile Client Apps (Glenn Stephens) – high level overview of building Xamarin apps with Azure
CQRS Secrets: How to Support Scalability and Performance (Richard Banks) – great intro to CQRS, from why to how
Blockchain 101 & Azure Blockchain as a Service (David Burela) – new hot thing from Azure
Blockchain Development on Azure Blockchain as a Service (David Burela & Chris Zhong) – deeper dive
30 Terrible Habits of Server and Cloud Administrators (Orin Thomas) – BEST VOTED SESSION OF THE CONFERENCE, title says all, and it also relates to developers’ habits

Summary

Microsoft Ignite Australia was very well organized conference. I had a pleasure to meet a lot of passionate and curious people there. If you are a speaker or developer looking for a good conference, I strongly recommend you to go. If you are not from Australia, don’t forget to take melatonin for 14h+ flight 🙂 Oh, and the location is great too!

Gold Coast, Australia


My notes from The Passionate Programmer

Chad Fowler - The Passionate Programmer

It’s been a while since I read Chad Fowler’s The Passionate Programmer.

Recently I found notes I did during reading it. I thought I would share them with you. It is tl;dr of every one of 53 chapters of the book.

1. Keep on radar bleeding edge technologies vs sunset technologies.
2. Follow job market requirements.
3. Understand business.
4. Be the Worst in the team so you can learn from others.
5. Learn/know different type programming languages (C#, C, python, prolog…).
6. Avoid fear-driven career choice.
7. Keep on radar known tech/platforms vs unknown(to learn).
8. Learn what is under abstraction layer of your programming language.
9. Use different technologies.
10. Log your excitement level over days.
11. Everyday learn something new about tech/tools you are using.
12. Learn how business work.
13. Have/find a mentor.
14. Be a Mentor.
15. Practice (Google Code Jam, Project Euler, Code Katas).
16. Know/learn Software Development Methodologies.
17. Read other’s code (and criticize it).
18. Automate tasks.
19. Do it now!
20. Predict the future – possible requested features (make it easy to implement it).
21. Make daily review (problems, processes to improve).
22. Understand your manager/company goals.
23. Set goals for you current job (long term).
24. Make boring tasks fun!
25. How much are you worth?
26. Share you areas of knowledge in job (implemented modules, deployment process etc.). Make documentation.
27. Measure (by metrics), improve, measure.
28. Work as hard as you can (no fb, twitter etc.).
29. Learn how to fail.
30. Say ‘No’ when you know you cannot do something.
31. Don’t panic.
32. Say It, Do It, Show It.
33. Be aware what others think about you (managers, team mates etc.).
34. Don’t make people afraid of you.
35. Track you decisions and analyze them (diary).
36. In person communication over email/Skype.
37. Have elevator pitch (business benefits of your recent work).
38. Have the mission!
39. Be present on-line (blog, twitter, LinkedIn).
40. Care about your brand (google yourself).
41. Contribute to open source!
42. Be remarkable (do something what will take a week in one day).
43. Propose changes/features to software you are using (mail author).
44. Be up to date with current/new tech.
45. Try to do your job as you are your manager.
46. Path is more important than destination.
47. Create map of your past, current and future career (and what your learn, when you lost time).
48. Try to be alpha geek (or follow some of them).
49. Ask your coworkers for feedback.
50. Avoid monkey traps (do not be too confident in some things, or review them from time to time; know your enemy – play with technology you don’t like).
51. Avoid Waterfall career planning.
52. Be better every day.
53. Try to go independent (e.g. 2 hours/day after work hours) – how much did you earn?

This book helped me to drive my career, and I am sure it will help you with your career!

Have you read this book? What do you think? Maybe you know some other books you would recommend?


[HockeyApp + VSTS] Generate release notes from last git commit message

Continuous Integration and Continuous delivery for Xamarin apps with VSTS and HockeyApp is awesome!

I blogged about setting up CI/CD pipeline with VSTS+HockeyApp a few weeks ago.

If you want to add release notes to HockeyApp release you have two options:

  1. Add release notes manually, by setting ‘Release Notes’ property, and update them before every build (AKA – option that sucks)
  2. Add path to release notes file, by setting ‘Release Notes (file)’ property, and update it before every git push (AKA – option that sucks less)
  3. Add path to release notes file, by setting ‘Release Notes (file)’ property, and generate release notes from last git commit message on every build (AKA – option that rocks)

Applying options 1 and 2 is easy.

To make option 3 happen you need to add script that will get last git commit message, and output it to the file that you specified in ‘Release Notes (file)’ property. This script should be executed before ‘Deploy to HockeyApp’ step (of course).

For Xamarin.iOS you need to add ‘Shell Script’ task that can look like this:

echo "last commit: $BUILD_SOURCEVERSIONMESSAGE" > commit.txt

*it will output file to the same directory where shell script is located

For Xamarin.Droid and Windows builds, you can create PowerShell script.