In 2012 Anders Hejlsberg started working on TypeScript (JavaScript for C# Developers with types).
In 2013 Eric Lippert left Microsoft.
In 2014 Jon Skeet wrote on his blog about C# inefficiency.
In 2015 JavaScript took over the programming language World for good.
In 2016 C# is getting more functional features from F#.
In 2017 C# is dead.
You probably have heard about The Joel Test. This test helps you to determine how good a software team is. It was created almost 17 years ago by Joel Spolsky (currently CEO of StackOverflow).
A lot of changed since then.
Here is The Joel Test for 2017:
What is missing? Let me know in comments!
Over four years ago I created a simple Pomidoro Windows App in order to learn Windows RT app development. Yeah! Windows RT was a new thing back then! My app was a simple timer that counts down from 25 minutes to 0. It was designed to use when applying the Pomodoro Technique. I published it to Windows Store as a free app. Since then me and a few friends of mine were using it. It made it to top 600 productivity apps on Win Store.
The main purpose of creating this app was to get insight into Windows RT apps development, and experience publishing app to Windows Store.
Last year, somebody from Pomodoro Technique filed Content Infringement Complaint stating that
App name has a name including “Pomodoro Technique®” and “Pomodoro®” or significative parts or misspelling of Pomodoro and Pomodoro Technique
What that means? My app, created over the weekend, is serious competition for their app. What’s more, they removed my app from Windows Store!
Recently, my friend Pawel Sawicz – who co-founded dotNetConfPL with me – asked me about this app. He was using it from day to day, but he got a new ThinkPad X1 Carbon Gen 3, and he had to install a new system. When he wanted to install my Pomidoro app from the Windows Store he couldn’t find it. He thought that the search was broken. Then he reached out to me, and I explained him the situation. Fortunately, source code is on github.
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.
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
When I am looking back, I am impressed how much the Azure Portal have changed over last two years. This is portal in 2014:
This is portal in 2017:
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.
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:
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!
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!
