New job

Long time no see 🙂 Have been busy working on an amazing project with Azure services, .net core, Xamarin with microservices architecture so had no time writing blog posts.

I have a new job now. Will go to my customer as CTO and still do some consulting from time to time as speaker, do workshops, mentor support, and mostly work with Windows System AB as CTO with a team. My role will be a team lead, architect, developer and keep up with innovations, trend analyses and so on regarding POS-Systems and digital commerce business.

What’s an DevOps Engineer?

I recently received a question “what is aDevOps Engineer”? There are many who seek such a person in advertisements. It sounds like a role but DevOps is anything else but a role.

DevOps is about breaking down silos between different parts of the organization and ensure that everyone is on the same page and working in the same direction together.
DevOps is a culture where you will get rid of the silos between as admin, developers, commission / operators, DBAs, Design, Architects, ux, product owners and get closer to the consumer.

If we look at the Lean and the Agile Manifesto principles, DevOps is almost the same thing including one important point that is missing in manifest today. Rapid feedback and fail fast. I would like to see the Agile Manifesto v2.0 with this important point. Give favor to “fail fast”

DevOps in itself does not differ so much from continuous delivery of software. Besides the support to move toward operations in the infrastructure, which among other things can be controlled from our code nowadays. We talk about IaaS, PaaS, IAC, saas, C, Cd, containers, et c.

An important part of Lean is to constantly seek improvements and reduce unnecessary work, which is an important part of DevOps. Employees also need to have different knowledge of tools to simplify work for quick delivery and continuously decrease  waste. Therefore, we need to simplify the work regarding our continuous delivery and  involve the operations in the entire application lifecycle. Therefore, it is important that everyone is part of the team, and share the same time box.

To do this, we simply need to get our organizations’ employees to live in a common culture.
– Communicate with your whole hand not just the little finger
– He/she concern spans the entire organization, not the immediate technology and product he/she is responsible for
– Understand the business and user he/she support, including internal users (dev, QA, sec, ops)
– Understands and has trained in Lean and Agile and can combine intuition with data
– Developers and operation should also share the same time-box as the rest of the team and are not treated as different

A “DevOps Engineer” is not a role or a type of developer or engineer. DevOps Engineer is talented employees with a certain part of the business, organizational and social skills. In other words everyone  shall be DevOps engineers and not just one person or two in their organization. DevOps is more or less about getting to a maturity level within the organization today, how we have to work to be competitive on the market and make it possible to satisfy the demands our consumers require.

Who is Johan Normén?

Johan Normén works as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015 and member of IDG Expert Network Team

Twitter: @johannormen

 

Feature toggling and A/B testing in production with ASP .Net Core

Do you remember the old days when we used asp 3.0 or earlier version and it was common to fix things in production? Ad-hoc was king, kind of, if you did not forget to add the changes to the source control.
The funniest thing with innovation is that we mostly take to steps back to jump three steps ahead. Feature toggling, A/B testing, DevOps, CI and CD and Hypothesis development make this test in production popular once again, but this time in a more controlled manner. Instead of change code in production and test it,  we simple want to do the same thing today but with automation, so we do not need to add or change the code in production to get the same result. We simple add the changes to our master code push it and it will get released into production for testing. In this blogpost I will give you some examples how you can manage this in a structured and simplest possible way.

First of all, what we want to do is test our ideas our hypothesis in production, we will also make it possible to turn feature on and off in production. Here is an earlier blogpost if you wonder why we want this.

and here https://johannormen.com/2016/04/07/how-pain-driven-developmentdesign-pdd-can-be-used-as-an-extension-to-hypothesis-driven-development-design-hdd/

To make this happen we need some discipline, first of all we must get rid of our pride to do the best possible solution from start, we don’t want to waste too much time (and money) to just get the information if a feature is worth implement as full scale. So we need a controlled AD-hoc approach. This can be solved with a feature toggle framework. I made one here, but feel free to use others.  https://github.com/jnormen/NS2.FeatureToggler

This frame work will help you to encapsulate the AD-Hoc code so it will be ease to remove and also easy to read.

You simple create a class that implements IFeature like this.
public <nameOfTheFeatureIWantToTurnOnAndOff> : IFeature

Eg: PressMeButtonText

And then use an if statement like
if ( Feature<PressMeButtonText>.Is().Enabled )

To handle nice CI and CD we also need a god structure in our solution. If you remember clean code that’s all about just clean code, it’s also important to have clean structure and architecture. In my case I love to use one project not many and also a folder called module, in this I put all the code for different domain boundaries. Kind of the same way we separate Microservices and so on.

A module can be everything regarding products, carts, invoices, users and so on. To indicate for the developers there is a test of a feature ongoing, I simply add a featuretoggle folder in my module. If there is no such folder then there is no feature on that module for test in production.
Here is where the discipline comes in. You really need to remove stuff you do not use to help others and yourself to understand what’s going on with the code, architecture etc. The same rule as for remarked code.

So this is how I made my folder and project structure:
1

Every code that is just for the FeatureToggler exist in this folder, the IFeature class, scripts, styles if needed. I use gulp for my build pipeline so I just let all the sass, less or js files to be included in my bundle if needed as well. Therefore, I also add the modules in my gulpfile. Eg:
1a

I also made a more advanced gulp-pipline to move views from my module to the views folder structure. I know it seems insane but I want all code to exist in my own module not laying around everywhere in the project. So if I want to update a view I do it in my module views and it will be copied to the views folder for ASP .Net Mvc to handle it. In this case I can delete the whole module folder and get rid of all the codes with just a click.

My feature toggle framework uses appsettings.json to turn off and on features. I also made it possible to add a method to my feature class if I want to do more advanced code to indicate if the feature is on or off. Like some A/B Testing routines, if a person is in a special role and so on.

This can be done by just implement a IsEnabled() function that return a Boolean on the class that implements IFeature. (This is a dynamic method so it’s not required by the IFeature implementation.)

public bool IsEnabled()
{
   … your special code to indicate if the feature is on or off…
}

To use the Configuration in ASP .Net MVC .Core just send in the Configuration to the static SetConfiguration method in your startup.cs
config2

To set a feature on and off this way simple add the class name and the value in appsettings.json like this
config

Now let say that I want to test if a person press my button if the text is something else then the ordinary button and color is red. (I know really bad example, but it’s just to show you how you can handle your code).

Go to the view you where you want to test your feature, add a razor if statement and all the code needed just for the test. It doesn’t matter if it’s inline code, remember it’s just a test, nothing more and nothing less.
2

I added my test style and my test script and my test button. Within my new feature. My old code is still there in the else criteria. Now I’m ready to push this little code into my master branch and let Visual Studio Team Services (VSTS) trigger the CI and build configuration and add it to production. A tip, you can use Docker or Windows Containers here as well for better testing benefits and so on. I do not use feature branches just my master. Therefore, it’s also important to have tests in your CI & CD pipeline. And here are why containers are so useful as well, easy to rollback and then fix if any problem with this newly added code.
For more information regarding feature toggle and source control
http://martinfowler.com/bliki/FeatureToggle.html

If you want to add the test on many different view I recommend to do some shared module and create an ad-hoc web components instead.

module
…..shared
……..featureToggling
………..scripts
…………..pressMeButton.Js

The build pipeline with gulp will include it as well so no manual work at all, beside creating the folders and the web component file. (Angular 1, 2, Aurelia, React, Ko or whatever you like.)
3.Ng

And in production we can see something like this. In this case the feature is off and we got the standard button.
off

And here it’s on.
on
Remember it’s also important to log data so you can evaluate what buttons get most clicks. So you can decide if this feature is worth implement in full scale.

Remove the feature
I did this feature framework help you with the cleanup. You can add if statements in the code without any framework, but then it can be harder to know where to clean up in your code. In this case, just delete the feature toggle folder in your module folder. And build your project.
4delete

You will then get compilation errors and it will help you clean up just that feature.

6delete

So just delete the if statement. Or add the new code in its place.

7delete

8delete

Easy right? The structure is self-explained, the code is mostly clean, the test is a was ad-hos solution just to save time to get data if it’s forth implement at all and so on.

 

Who is Johan Normén?

Johan Normén works as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015 and member of IDG Expert Network Team

Twitter: @johannormen

 

 

 

A reminder of the agile principles

It’s very common that people refer to the agile manifesto and then add another explanation to it. So I just added the agile principles as a reminder.

You haven’t forgot them right?:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Source: http://www.agilemanifesto.org/

A mature maturity model for continuous delivery including culture and DevOps

Do you love the idea of a model that rules them all? I bet you have, we all have 🙂

“Devops has huge business benefits: Statistics show that organizations that practice devops outperform the SMP500 over a 3 year period, high-performing IT organizations have 50 percent higher market cap growth, and so on.”

I have ben fan of models in my whole life (kind of, since I remember anyway). The idea with a model it that it’s not a process. It just helps you understand things. While a process is how you shall navigate. I’m not fan of processes. I love to create them though, for others. It might sound rude but I’m a creative person that love to be on the top of the wave. Processes can’t make me think outside of the box or live outside it so I just creates them for others that don’t have time or interest to be on the top of the wave all the time. My daily activity in my head loves the ideas of innovation, efficiency – how can we make it easier and still with high quality? How can we do it in such a way that we do not need to do a lot of bad work when we want to change something? These are the questions I always ask myself every day in all areas. I can not stand the feeling to stand still and be smug. I am a thinker who loves changes. I’m curious person.

The last 10 years or so I have always been interested in different working models/processes. Therefore ALM (Application Lifetime Management) became an interesting area for me. Agile processes, gamification and so on.

We have this constant goal and vision to work towards something better. It shall be easy to make adjustments to the code and the architecture. It shall be easy to delete code that is not used anymore and, last but not least it should be fun and innovative approach to work with software development and deliver a smile on the customer’s lips every time. Faster deliveries and keep up with the competition has never been more important than now. Before, it was easier to become complacent and just sell on. Today we cant work this way if we want to keep up.

drastolen

Today we talk about agile delivery, continuous delivery. We’re talking about spending less time on code problems with smart and effective continuous integrations. We talk about the importance to measure value via monitor behaviour etc. We’re talking also about saving time in testing, operations and so on in order to keep up. To help and make managers and buyers less busy, several companies worked to develop various maturity models. With the main goal to be able to run faster delivery and early take part of the digitalisation and its digital transformation taking place today.

I wrote myself a Swedish post on my LinkedIn about five maturity levels for the  transformation regarding better continues delivery benefit.

Level 1 – A few develop are the organisations super heroes (Ad hoc solutions)
Level 2 – Time-Boxed releases
Level 3 – Regular deliveries
Level 4 – Release Command
Level 5 – Hypothesis-driven development

I recently wanted to find a model that explains all this in a more technical level. To help companies to identify where you are in the area of DevOps, test, code, culture, processes and so on. I have read four different maturity models from four different companies. But I didn’t like them. Most of them feel like they were created based on other companies’ problems and not based on a general level. A colleague of mine gave me a link to a model that actually is a great addition to the five levels I previously presented.

The model comes from the company Praqma. Not only that it is presented nicely, it is also spot on based on my thought and experiences in that field. The expert step is a great addition to #NoEstimate, Lean Startups with Hypothesis-Driven-development/Design and Pain-Driven-Development/design as the level 5 above.

cd-maturity

You can read more about it here
http://code-maturity.praqma.com/

If you are interested how you can work or how a system need to be designed and what transformation you need to do to reach the expert level, don’t hesitate to contact me or read my blog and forthcoming posts.

Who is Johan Normén?

Johan Normén works as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015 and member of IDG Expert Network Team

Twitter: @johannormen

How Pain driven development(design) (PDD) can be used as an extension to Hypothesis driven development (design) (HDD)

Earlier I wrote a little bit about HDD (Hypothesis Driven Development) and also how you can use it as an example with Microsoft .Net and JavaScript. This time I will talk about something that can be used as an extension to HDD.

In the topic I added the word (design) after the word development. I did this for a purpose. When we talk about development we usually refer it to just code, but the whole process even if it’s visual design or system design you develop something. But sometimes organizations just do design or work on just the visual design. The process is the same even if it’s in code or in the visual design or even on a paper.

While HDD is a story about an assumption/idea that we need to measure to see if it’s worth implementing. Pain Driven Development is an extension when your product enters the state of management. You will still use HDD for new features but PDD when you need to understand how you can make your features better.

“If you can identify something that is causing people pain and you can develop a product that takes that pain away, that product is very likely to be successful. The goal is to find the most important pain point and then to find a way to solve that pain for people in a usable way that doesn’t actually cause them more pain.” – Laura Klein
PDD is when you focus on the pain and frustration your application generates for the user. The question you ask the user is:

– How does the function make you feel?
– What is complicated with the application?
– What can make your work easier so it wont generate frustration or irritation using it?

You can use PDD as the process to make the application easier for the user. And of course HDD to test the hypothesis of the ideas you get from the PDD process. They are very nice to use as a synergy to each other. And the result will mostly give the user what they want.

If you use it in your development process, it’s fine. If a developer scream WTF (you know the WTF / minute principle right?)

wtfm

Code shall be easy to understand, easy to use. With PDD as a part of your code quality process you can easily find pain points that probably need to be fixed as soon as possible or in a near future.

You can also use PDD in your organization. Isn’t it a real pain that you only got 2 toilets for 100 people? 😉 You get the point.

 

Who is Johan Normén?

Johan Normén works as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015

Twitter: @johannormen

 

 

Hypothesis Driven Development with example

My previous blog-post was an introduction to HDD (Hypothesis driven development). In this blog post I will take it a step further and give you an example how you can use it and how easy it can be and how it can change the way you work entirely to a new level.
You can read it [here].

Remember:
HDD is an experimental driven process, it’s main goal is to find out if a certain idea generates ROI and happy users. To get fast result you will also need fast support to evaluate your experiment, if you want to evaluate the idea in production I prefer a smooth decoupled architecture and a mature CI & CD organization. It’s not a must to, but it will really decrease development time and cycle time.
Sadly, I have no maturity model written in English yet. You can read one I did in Swedish on my LinkedIn posts [here]

Let’s start the story.

Team:  A cross-functional team with talent people regarding:
Design, UX, Coding, Testing and so on. And also including some market people and product owner.

At a meeting with the customer and team a team member (TM) got this cool idea regarding an e-commerce platform.

– What if the stock value changes in real time? Wouldn’t that be cool? Maybe it increases the conversion rate? The users might be stressed that this nice shoe will get out of stock?

A business person (BP) responds:
– What will it cost? Can you estimate?

– I don’t know, and I don’t. And I don’t know if my hypothesis even works. Can’t we skip this estimating and cost discussion and find out and then see if it’s worth implementing at all?  (TM)

– How? (BP)

– Let’s just do some A/B testing and fake a simulation of stock value changes and monitor if the user will buy the product more often or faster than today? If we get an 2% increased conversion rate it really worth implementing isn’t it?  (TM)

– Yes, you got a points there, this Sounds interesting. (BP)

Instead of creating User Stories the team now write Hypothesis stories.

Real-Time stock value changes
We Believe That
real-time stock values on the product page
Will Result in improved customer engagement and conversion
We Will Know We Have Succeeded When we see a 5% increased speed and about 2% conversion increase from the time the stock change in real-time till they press the add to cart button.

The meeting generate lots of hypothesis stories and the product owner can now prioritize them based on the ROI for the result outcome.

– A 2% increased conversion rate is really nice. Today we got like 5000$ each day, 2% will give us about 100$ more. In a month it’s around 3000$. If the experiment works and generate this value; You can spend around 30h of development time and we still get more money than not implement it at all. (BM)

– Yes you can say that, but let’s not convert it to time yet, let’s see if it’s worth implementing at all. Because if we spend around 10-30 hour for this feature and it will not increase conversion at all; we just wasted lots of money for developing a crappy feature. Let’s be smart and just spend time creating features that generate values in short and long runs instead. Assumptions is not a good thing. (TM)

– Ok, we can give it a try, because we have done so many bad assumptions we even can’t monitor at all. (BP)

The Product owner decided to activate the experiment and tells the team to do the fastest possible implementation to get information to see if this hypothesis will generate values at all.

The team gathered as usual at a stand-up and activated the work of the hypothesis.

– So what is the fastest possible solution to get rapid feedback regarding this? (TM)
– We can ask the customer?
– Nah, the customer might say, cool feature or – Do you want to stress us even more?
– Ok, let’s implement a test in our code and monitor the outcome?
– Sure, what’s the fastest way?
– This is part of the UI so let’s do it simple with some JavaScript. The only thing we need to understand is if it works. So there is no need to make it perfect. We do not need to add back-end functionality to get this information either. I can type a JavaScript that just randomly decrease the stock-values on some products. And then monitor with our application-insight code if they will press the button faster or not. It doesn’t matter if the stock value is a faked value for a while… If the value is 5 or 4 doesn’t matter that much.
– Nice, cool this will take us around 15 minutes or so? And thanks to our CI  & CD approach the feature will be out within 20-30 min or so and we can then start monitor it. If the result is good, then we implement it all the way with tests and quality in mind.
– Cool, this is nice, if the PO asked us to estimate it and add management work around it and do all the other stuff we do for a user story it would take longer cycle time than 30 minutes for just get started on this one. We aren’t wasting anything here, just getting knowledge and information if the idea is worth implementing or not. We will save around 15 minutes and also get the information if it’s even worth implementing. It’s much better than assume it does by implement it and hope it will generate values.

The team agreed.

Liza loved the idea regarding NoPSD so instead of spend time on working with PSD files or other tools for design she just opened the SASS file (css manipulation) and added three new classes with three different color. Green for normal stock values, Orange that indicate near out of stock and red that indicate very soon out of stock.

.stock-Normal
{
     color: #38893d;
}.stock-Warning

    color: #fe8f01;
}
.stock-Critical

    color: #be0000;
}

Thanks to nice SASS structures it just took her 2 minutes. When she pushed the code to the source control it automatically generated a new css file that got released into production, this because the team had nice CI & CD approach. (Why not release it? It will not hurt anything though nothing using the classes at the moment anyway.)

The front-end was built on AngularJs and the stock area was created as a web component and rest of the system is based on ASP.Net MVC and Web Api. Meanwhile Liza added the css John added a feature toggle in the code and took the html from the web component template and added it to the new feature for the hypothesis.

The feature toggle framework they use uses one configuration file to indicate if the feature is on and off.
They simple add it as an appSetting in web.config or appSettings.json (if using ASP .Net 1.0 Core).

“IRLStock” : “true”;

The team uses a framework that uses a C# class as a feature toggle so they easy can remove the class and get compilation error where the feature existed, so they do not forget to remove the code later on.

public class IRLStock {}

The code with razor syntax (ugly code? I know but much faster than create a new web-component to get the result from this experiment, it’s important to not waste unnecessary time for a more complicated solution, then you missed the whole point. This code will be deleted after the experiment anyway. For experiments it’s just waste to add sugar to it.):

@if(Feature<IRLStock).Is().Enabled)
{  
     < script >
… a script that just gets a random number between 2-6 seconds…
… this number just trigger a interval eg.
setInterval(changeStock, randomNumber);..
..
and set a new class to the element…
getElementById(“stockDemo”)…

< /script >

< div class=”stock-number” id=”stockDemo”>< /div >
< div class=”stock-text”> In Stock< /div >
}
else
{
<stock-indicator></stock-indicator>
 //Old code that works. If feature is turned off the ordinary code will run. An easy way to turn on off features, you can even turn on feature in dev mode but disable it in production mode…

}

John started the page to see if the script worked as intended. He didn’t create any tests since the code will be deleted as soon the experiment is done.

It worked. So he pushed the code, the CI & CD took care of everything and now the experiment was live.
It took him only 15 minutes.

And the result:

 

Two weeks later:
The PO asked the team how the experiment went. The team showed the PO the monitored data they have gathered. It didn’t show any direct speed increase only 0.5% faster than average. But the conversion rate was higher than before. 1.8%. So the hypothesis with the goal of 5% increased speed and 2% conversion rate did not work. But it still generates 1.8% conversion rate. The PO was not fully convinced if the feature was that good so he wanted to test the experiment one more week.

One week later:
Still the same result 1.8%.

– Ok the experimental code just gave us about 2400$ extra income. That’s nice, lets implement it. Is it possible to get it done within a week or two? (BP)

– Sure, we already have the infrastructure with SignalR since before so we just need to add a new REST API in our Asp .Net Web Api module for the product page. We already have code for retrieving Stock   values in our validation of the cart so thanks to our SOLID approach with SRP (Single responsibility principle) we already have a repository method to retrieve the actual stock value for an articleid.
The style we added can be reused, no need to change that; we just need to add the event handling in our Angular web-component for the stock indicator. It will not take that long either though we only need to act on the event triggered from SignalR and add the new stock value to our view model. Add some code that switch the class based on the stock value. I think with tests we will have this implemented up and running within few days or in a week. Especially thanks to our CI & CD approach and our architecture. (TM)

– Nice. Let’s create a user story and add it to the backlog (BP)

Summary
Sounds too easy right? Like a Utopia? I know, but it’s not. With good agile organization mindset, with well-educated team, with good CI & CD, DevOps and architecture it will be easier than before. As humans we mostly do things too complicated, and thanks to a lack of slack in organizations you don’t have time over for the team to be more innovated and creative in learning.We need time to invent things easier and better than last time. Continuous improvement is so important so don’t waste that benefit.

 

Who is Johan Normén?

Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015

Twitter: @johannormen

 

 

Implement HDD (Hypothesis driven development – Part of Lean Startup) with #NoEstimate

I remember when I study Information Technology in college (1995), we published local newspapers for our school. I’m not that good writing articles so I mostly worked with the layout and ideas to make the paper look great. My talent was used for the cover and also to make the paper more user friendly. To do this I tested lots of ideas with the team and with survey,  interviews and we monitored what worked best for our readers. We also had another competitor who also launched a newspaper at our school.

I remember one time when I wanted to add a little tag on the upper left corner. A tag with black background and white uppercase words explaining what section you where on. Like SPORT, MEDIA, GOSSIPS, GAMES and so on. I wanted this because I thought it will make it easier for the readers to remember what section they where on and also an indicator so the reader can jump to the most interested section without reading the table of contents. We added this section topic tags on each page as a test.

One week later we asked the readers what they think about the new version. Most of them pointed out that it was really nice with the section topic tags but they wanted to us to add the page number up in that corner as well. Some other stuff was bad so we removed that in the next number and added the page number in the upper left corner as the user wanted. We used reusable template so it was an easy fix.

Two months later, our competitors also took this idea to their newspaper. At this point we got a better colored RGB-printer so we removed the section topic tag names and colored the background instead. Why read the topic when you can see the topic? Blue for sport, red for gossip, yellow for fashion and so on. It worked even better, the user thought some colors felt wrong for some sections, so we changed the color based on the user inputs and they where happy. Guess what our competitor did later on?

Some ideas were great so we kept them even if the competitors copy us. We still sold more newspapers then them. Because we tested new ideas and listened to our readers all the time to get rapid feedback. We engaged our readers. And it was important for us to fail fast if our ideas were bad. It’s our readers who pays us so it would be bad idea not listen to them. How often do you ask your users what pain them the most with your software and what change they expect? What functions can you delete to clean up the code from smells and other unnecessary things that are not used anymore? Do you monitor how the user use your software?

In this post I will give you some introduction and guidance of some practices regarding how you can make this possible with HDD and #NoEstimate.

HDD (Hypothesis driven development)
As development industry continues to mature, we now have an opportunity to leverage improved capabilities with Continuous Design and Delivery to maximize our potential to learn quickly what works and what does not for the users. To do this we need to engage the user or monitor the user’s actions. We need to learn from them not just teach them.

Are you familiar with User Stories and maybe even BDD (Behavior riven development?)

User story focused on capturing requirements for what we want to build and for whom and why. The main goal is to enable the user to receive a specific benefit from the system.

User story format:

As a…  <user>
I Want… <something>
So That… <I receive benefit>

User story are mostly common in the process when some market people or it-leaders have decide what shall be built. It’s not uncommon that the selection of user stories is based on the estimated time rather then the real user value. – Is X that big? Then let’s skip it, we need to give the user features fast and can’t spend time on the most expensive once.

(BDD) Behaviour Driven Development takes us to the next step. It aims to improve the user stories by supporting communication and collaboration between developers, tester and non-technical participants in a software project.

In Order To… <receive benefit>
As A… <role>
I Want… <goal/desire>

User Stories and BDD stories are both often created within the development process as a result of already prioritised features that will be built based on our definition of done and so on. But how value-driven is that? Do you really know if that feature will be used by the users? They might say “we need it!” if you ask them, but will they use it? Is it worth spending time to estimate something you are not sure if a user really need? Is it worth develop a user story with high quality and release it month later if the user wont even use it anyway? What about the feature Y you decided to skip because it was estimated to high? We need to view our work as an experiment to really find out. We need to ad a better process for innovation and monitoring what pains the user most to understand what benefit them the most. We need to learn from the users, not the value of an estimate or assumptions.

When viewing work as an experiment, the traditional story process is insufficient. As in college when we defined the steps we needed to achieve the desired outcome. We need to observe if our idea (hypothesis) is valid.

If we observe signals that indicate if our idea or hypothesis is correct, we can be more confident that we are on the right path and can alter the user story process to reflect this.

Keep in mind that a hypothesis that was once valid may later be disproven when markets change. Markets move, so you need to continually ask whether the business model is still valid or not. HDD is value-driven and the market is too.

A hypothesis story can be implemented with different technologies and tools, the main goal with a hypothesis is the explanation what action you need to implement to get the indication if it worth implementing.

We believe… <this capability>
Will result in… <this outcome>
We will know we have succeeded when… <we see a measurable signal>

Examples of Hypothesis-Driven Development user stories are;
We Believe That real-time stock values on the product page
Will Result In improved customer engagement and conversion
We Will Know We Have Succeeded When we see a 5% increased speed from the time the stock change in real-time till they press the add to cart button.

Why I mentioned #NoEstimate in this post topic is because you do not estimate when wotking with hypothesis, you just use the easiest and fastest tools to reach your goal, so you can take action if it’s worth implement it as a full qualified feature in your system or not.

Lean startup and UX for Lean Startup will explain more how. I will not cover this in this blogpost, it’s almost to big as is.
A hint: Instead of write user story, spend time estimating and then build all the technical stuff regarding real-time stock value changes, just add a simple timer in javascript that decrease the stock value on different products to see if the user reacts on it. If not, then you have saved lots of time not implement a fully working feature. I can promise you that it’s worth spending less then one hour to implement some test data rather then add a push or pull system (with eg. SignalR?) that monitor the stock values in the e-commerce platform you use.

To use value-driven-design and HDD you need to change the way your organization work and also the traditional mindset of yours.

Some methods you need to add to your organization are:
– Increase observations
– Formulate a hypothesis
– Design an experiment to test the hypothesis
– Evaluate if the experiment has succeeded
– Conduct the experiment
– Evaluate the results of the experiment
– Accept or reject the hypothesis
– If necessary, make and test a new hypothesis

To make this possible you also need the developers to be more mature in the way they craft. HDD requires that you write code that is easy to test, profile, benchmark, and change. They need to learn about A/B Testing and how to implement it to the code.
A more mature model for CI (Continuous integration) and CD (Continuous Delivery) are also a must for even bigger benefits. Other useful techniques can be feature toggling (can be used for A/B Testing) and also rapid development for releasing and remove measured and monitored prototypes, dark launches and even live ops.

“By combining Continuous Delivery and Hypothesis-Driven Development we can now define working software and validated learning as the primary measures of progress.”
– Thoughtworks

Traditional process vs HDD process

Traditional process
1. PO add epics, features or user stories in a backlog.
2. Team estimate the items
3. PO decide what items need to be implemented (often based on time and cost)
4. The team implement the feature
5. The team release the feature
6. The process starts over from 1-6 again.
(7). Team spend time on supporting and maintain released software.

Result: Something will be implemented and released, but it’s uncertain if its what the users really want.

HDD process
1. The organization make observations
a. Ask the support people what makes the users scream the most
b. Ask the team and acceptance testers what features are hardest to test
c. Interview real users and also create personas if hard to get interview, or use both
d. Record users using the software to get indication of the impression and feelings etc…
e. Look at trends, competitors
d. Monitor and measure the app (buttons clicks, sequence orders, timers etc..)
(Did you know that people mostly use only about 10%-20% of all features in one
application?)
2. Formulate the hypothesis.
3. Design what’s needed to experiment the hypothesis.
(see: Lean startup, Lean startup ux for more inspirations.)
4. Evaluate the result of the experiment
(If you need to implement a monitored A /B Testing and  prototype, remember you need   some time to collect that data. It’s better to wait for a result then spend lots of            unnecessary time to implement something that takes time and never gets used and spend that time on the most valuable features instead)
5. Accept or reject the hypothesis.
(If rejected, start over from 1 or continue from 3)
6. Make a User story of the accepted hypothesis.
(#NoEstimate: There is no need to estimate the user stories, at this point the users have already told you they will use the feature and need it. Save unnecessary waste instead and spend time to continuous improve your CI & CD process instead.)
7. Implement the user story and release with CI  & CD in mind.

Result :
You will mostly spent time on feature users really want that gives you the best value and ROI. You don’t waste time on features that never get used. And the whole HDD process is like an innovation process as well. So you get that as a bonus too.

If you liked this, please read: Hypothesis Driven Development with example

 

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015

Twitter: @johannormen

 

The Pragmatic Programmer Quick Reference Guide

  1. Care About Your Craft

Why spend your life developing software unless you care about doing it well?

  1. Think! About Your Work

Turn off the autopilot and take control. Constantly critique and appraise your work.

  1. Provide Options, Don’t Make Lame Excuses

Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

  1. Don’t Live with Broken Windows

Fix bad designs, wrong decisions, and poor code when you see them.

  1. Be a Catalyst for Change

You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.

  1. Remember the Big Picture

Don’t get so engrossed in the details that you forget to check what’s happening around you.

  1. Make Quality a Requirements Issue

Involve your users in determining the project’s real quality requirements.

  1. Invest Regularly in Your Knowledge Portfolio
    Make learning a habit.
  2. Critically Analyze What You Read and Hear

Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

  1. It’s Both What You Say and the Way You Say It

There’s no point in having great ideas if you don’t communicate them effectively.

  1. DRY – Don’t Repeat Yourself

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

  1. Make It Easy to Reuse

If it’s easy to reuse, people will. Create an environment that supports reuse.

  1. Eliminate Effects Between Unrelated Things

Design components that are self-contained. independent, and have a single, well-defined purpose.

  1. There Are No Final Decisions

No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.

  1. Use Tracer Bullets to Find the Target

Tracer bullets let you home in on your target by trying things and seeing how close they land.

  1. Prototype to Learn

Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.

  1. Program Close to the Problem Domain

Design and code in your user’s language.

  1. Estimate to Avoid Surprises

Estimate before you start. You’ll spot potential problems up front.

  1. Iterate the Schedule with the Code

Use experience you gain as you implement to refine the project time scales.

  1. Keep Knowledge in Plain Text

Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.

  1. Use the Power of Command Shells

Use the shell when graphical user interfaces don’t cut it.

  1. Use a Single Editor Well

The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

  1. Always Use Source Code Control

Source code control is a time machine for your work – •you can go back.

  1. Fix the Problem, Not the Blame

It doesn’t really matter whether the bug is your fault or someone else’s – •it is still your problem, and it still needs to be fixed.

  1. Don’t Panic When Debugging

Take a deep breath and THINK! about what could be causing the bug.

  1. “select” Isn’t Broken.

It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

  1. Don’t Assume It – •Prove It

Prove your assumptions in the actual environment – with real data and boundary conditions.

  1. Learn a Text Manipulation Language.

You spend a large part of each day working with text. Why not have the computer do some of it for you?

  1. Write Code That Writes Code

Code generators increase your productivity and help avoid duplication.

  1. You Can’t Write Perfect Software

Software can’t be perfect. Protect your code and users from the inevitable errors.

  1. Design with Contracts

Use contracts to document and verify that code does no more and no less than it claims to do.

  1. Crash Early
    • dead program normally does a lot less damage than a crippled one.
  2. Use Assertions to Prevent the Impossible

Assertions validate your assumptions. Use them to protect your code from an uncertain world.

  1. Use Exceptions for Exceptional Problems

Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.

  1. Finish What You Start

Where possible, the routine or object that allocates a resource should be responsible for deallocating it.

  1. Minimize Coupling Between Modules

Avoid coupling by writing “shy” code and applying the Law of Demeter.

  1. Configure, Don’t Integrate

Implement technology choices for an application as configuration options, not through integration or engineering.

  1. Put Abstractions in Code, Details in Metadata

Program for the general case, and put the specifics outside the compiled code base.

  1. Analyze Workflow to Improve Concurrency

Exploit concurrency in your user’s workflow.

  1. Design Using Services

Design in terms of services – independent, concurrent objects behind welldefined, consistent interfaces.

  1. Always Design for Concurrency

Allow for concurrency, and you’ll design cleaner interfaces with fewer assumptions.

  1. Separate Views from Models

Gain flexibility at low cost by designing your application in terms of models and views.

  1. Use Blackboards to Coordinate Workflow

Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.

  1. Don’t Program by Coincidence

Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.

  1. Estimate the Order of Your Algorithms

Get a feel for how long things are likely to take before you write code.

  1. Test Your Estimates

Mathematical analysis of algorithms doesn’t tell you everything. Try timing your code in its target environment.

  1. Refactor Early, Refactor Often

Just as you might weed and rearrange a garden, rewrite, rework, and rearchitect code when it needs it. Fix the root of the problem.

  1. Design to Test

Start thinking about testing before you write a line of code.

  1. Test Your Software, or Your Users Will

Test ruthlessly. Don’t make your users find bugs for you.

  1. Don’t Use Wizard Code You Don’t Understand

Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.

  1. Don’t Gather Requirements – Dig for Them

Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.

  1. Workwith a User to Think Like a User

It’s the best way to gain insight into how the system will really be used.

  1. Abstractions Live Longer than Details

Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.

  1. Use a Project Glossary

Create and maintain a single source of all the specific terms and vocabulary for a project.

  1. Don’t Think Outside the Box – Find the Box

When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”

  1. Start When You’re Ready.

You’ve been building experience all your life. Don’t ignore niggling doubts.

  1. Some Things Are Better Done than Described

Don’t fall into the specification spiral – •at some point you need to start coding.

  1. Don’t Be a Slave to Formal Methods.

Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.

  1. Costly Tools Don’t Produce Better Designs

Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.

  1. Organize Teams Around Functionality

Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.

  1. Don’t Use Manual Procedures
    • shell script or batch file will execute the same instructions, in the same order, time after time.
  2. Test Early. Test Often. Test Automatically

Tests that run with every build are much more effective than test plans that sit on a shelf.

  1. Coding Ain’t Done ‘Til All the Tests Run

‘Nuff said.

  1. Use Saboteurs to Test Your Testing

Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.

  1. Test State Coverage, Not Code Coverage

Identify and test significant program states. Just testing lines of code isn’t enough.

  1. Find Bugs Once

Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

  1. English is Just a Programming Language

Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.

  1. Build Documentation In, Don’t Bolt It On

Documentation created separately from code is less likely to be correct and up to date.

  1. Gently Exceed Your Users’ Expectations

Come to understand your users’ expectations, then deliver just that little bit more.

  1. Sign Your Work

Craftsmen of an earlier age were proud to sign their work. You should be, too.

Languages To Learn

Tired of C, C++, C#, F#, and Java? Try CLOS, Dylan, Eiffel, Objective C, Prolog, Smalltalk, or TOM. Each of these languages has different capabilities and a different “flavor.” Try a small project at home using one or more of them.

The WISDOM Acrostic

What do you want them to learn?

What is their interest in what you’ve got to say?

How sophisticated are they?

How much detail do they want?

Whom do you want to own the information?

How can you motivate them to listen to you?

How to Maintain Orthogonality

  • Design independent, well-defined components.
  • Keep your code decoupled.
  • Avoid global data.
  • Refactor similar functions.

Things to prototype

  • Architecture
  • New functionality in an existing system
  • Structure or contents of external data
  • Third-party tools or components
  • Performance issues
  • User interface design

Architectural Questions

  • Are responsibilities well defined?
  • Are the collaborations well defined?
  • Is coupling minimized?
  • Can you identify potential duplication?
  • Are interface definitions and constraints acceptable?
  • Can modules access needed data – when needed?

Debugging Checklist

  • Is the problem being reported a direct result of the underlying bug, or merely a symptom?
  • Is the bug really in the compiler? Is it in the OS? Or is it in your code?
  • If you explained this problem in detail to a coworker, what would you say?
  • If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
  • Do the conditions that caused this bug exist anywhere else in the system?

Law of Demeter for Functions

An object’s method should call only methods belonging to:

  • Itself
  • Any parameters passed in
  • Objects it creates
  • Component objects

How to Program Deliberately

  • Stay aware of what you’re doing.
  • Don’t code blindfolded.
  • Proceed from a plan.
  • Rely only on reliable things.
  • Document your assumptions.
  • Test assumptions as well as code.
  • Prioritize your effort.
  • Don’t be a slave to history.

When to Refactor

  • You discover a violation of the DRY principle.
  • You find things that could be more orthogonal.
  • Your knowledge improves.
  • The requirements evolve.
  • You need to improve performance.

Cutting the Gordian Knot

When solving impossible problems, ask yourself:

  • Is there an easier way?
  • Am I solving the right problem?
  • Why is this a problem?
  • What makes it hard?
  • Do I have to do it this way?
  • Does it have to be done at all?

Aspects of Testing

  • Unit testing
  • Integration testing
  • Validation and verification
  • Resource exhaustion, errors, and recovery
  • Performance testing
  • Usability testing
  • Testing the tests themselves

    https://pragprog.com/

 

A swedish article with me regarding Microservices

Mikrotjänster är snabbt på väg att bli ett populärt sätt att bygga arkitekturer för applikationer och tjänster.

Capture

Mikrotjänster, microservices, innebär som namnet antyder att applikationer och webbtjänster byggs upp av små delar. Då kanske du tänker att det handlar om miniversioner av tjänster i tjänsteorienterade arkitekturer (soa)? Nej, inte riktigt.

– Det finns flera skillnader mellan soa och mikrotjänster. En är att en mikrotjänst är mindre än en soa-tjänst är och istället för kommunicera med hjälp av scheman och kontrakt så används klasser, då det i praktiken är frågan om rest-lösningar, säger Johan Normén, utvecklare och agil coach på konsultföretaget Softhouse i Göteborg…

Läs mer: http://techworld.idg.se/2.2524/1.652228/mikrotjanster-utvecklare

Who is Johan Normén?
Johan Normén is 37 years old, work as a speaker, mentor, team leader, agile coach, and senior .net developer at Softhouse in Gothenburg Sweden. He has over 18 years business experienced and worked in many different projects and roles. Was one of the creators of Swenug (Sweden .Net User Group) with over 3000 members all over the country. He started the computer era as game designer at the age of 12 with his Amiga and team. He has been nominated as the top 10 developers in Sweden in the Swedish version of Computer Sweden 2015

Twitter: @johannormen