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

 

 

Why Microservices and continuous deployment (delivery) is win / win

Microservices is nothing new but has become a standard in many systems during the last years. There have been trends in architectures some engineers use them as a silver-bullet. They used the Architectures even if not required by system nor requirements. DNA, 3-teir, SOA, DDD, CQRS, Onion architecture and so on. Is Microservices just a trend that will destroy systems because people will use it as a silver bullet? Maybe! The future will tell. Let’s investigate why microservices will be a good benefit for the continuous delivery approach.

 

As most of you know by now, is that continuous delivery (CD) is an approach to deliver functionality in a smooth and almost automatic throughput. CD is an extension to Continuous Integration (CI) that are the configuration that tells you something will happen as soon you check in your code in to your source control. It can run tests, if it fails it will not publish the system or do something else that’s important four you and your business. I use CI to tell the build server to build my system, run some test and send it to production with continuous deployment.

The different between Continuous Deployment and Delivery is just that deployment automatically deploy your code when delivery just give you a package that you can manually deploy

softhouse_CD_loop2_new3

As always it is requiring discipline in your mindset as well in your code. It will be forced since you release everything in to production. So why is microservices a win/win with this approach?

The opposite to microservices architecture is the monolithic systems, it’s a system with a server where all your business capabilities are grouped into one big product. With continuous deployment and delivery, we just need to release lots of code and run lots of tests, this can be tricky for the benefit of a smooth delivery. Maybe you need to migrate your database, change many contracts and increase a big and complex domain model every time you will push some new feature to your CI/CD configuration. You can save you lot of problem with feature toggling but you still need to release the whole system. This is when the micoservice architecture will save you from lots of headache. Micorservices are like small systems with their own architecture, components and tools needed for your business capabilities. I often explain them as CRUD services for different business areas like a product service, invoice service, order service, authentication service and so on. I also like to refer to them as a SOLID principle architecture on an architectural level rather than just on the code level.

Microservices shall have single responsibility (S) for its business area, it shall be designed open for extension (O), like version controlled REST APIs. A new version extends its functions. With backward compatibility you will have a subtypes of the API (L) and so on.

scaling_agile_model1scaling_agile_model1

Microservices allows you to deploy specific services instead of the whole application when minor changes is applied. You simply deploy that service and only that service code. If you use containers like Windows Containers or Docker you have even better CD benefits though you don’t need to replace any files on the already running service, you just deploy a new container and can easy activate that one as soon you feel comfortable doing so. With other tools like Azure service fabrics you will get even more nice supporting tools for crashes, rollbacks for versions if one deploys fails etc…

Microservcies also benefit from less merge problems despite the fact that it is simple to use different microservices within your team. Discipline implementation of feature toggle minimize the feature branches so you really go Lean with the whole architecture and spend less time on configuration management.
Summary:
– Less code within the codebase

– Less problem with merges if using feature toggling, version handling instead of     branches

– Less problem with deploys though you now deploy the whole system, just a   small part of it

– You will have benefits regarding scaling each heavily loaded service instead of scale up the whole system

And lots more… But remember, this is not another silver bullet, it’s just a bullet of many

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

 

 

 

 

Get rid of some concerns and unnecessary waste when coding for Continues delivery with ASP.Net mvc

I love simplicity I love the creativity of doing things as simple as possible, with the knowledge I have today. I know my knowledge is limited so therefore I always try to get new ideas, networking with people to get new input to create something even better or simpler than I did before. It is my way to continue learning and to improve and grow within my domains.

I do like source control frameworks like Git but I do not love the idea of spending too much time on management of branches, migrations and so on. Therefore I’m in love with the idea of creating SRP modules (single responsibility Principle). I want the integration part within continuous integration to work as smoothly as possible in order to get rid of unnecessary waste from merge-management and so on. This is another reason why I love the idea about Kanban regarding work on one task at a time combined with DoD (Definition of Done) before you start another one. When doing that, you will have finished components, which you can release without any problem. There is no point in not releasing, or there is no harm if doing so, unless it’s a change request of already existing feature that can’t go live at the moment.

No other users will use your components as long it’s not connected to an existing released feature. So in theory there is no problem to work with your main branch most of the time, you do not need to create a new feature branch and handle merge if that branch comes behind and such. It’s just bad waste.

Think of ASP .Net MVC Controllers, the only feature the controller gives you is the action you call, right? So if you release a controller that no one knows exist then the feature can’t harm the system right? Each controller has its own view, its own code, and if you use CQRS or Micro Service Architecture you mostly do not share functions with other controls or modules. The same should be true for other design-patterns like DDD-modules. What happens if you release a controller and all the parts are not fully done yet? Nothing right? It’s just there, it occupies some bytes on the server but it won’t break anything. Why spend time on administrations, configurations, management work regarding different branches when there is no need? You can let those controllers and features go live in your continuous integration, delivery and deployment workflow. OK, if someone manipulate the URL they might trigger this controller and that’s not OK. So I made a tiny little Action Filter that can handle this for me.

What about release you Controller module and only get access to it if a debugger is attached or you are in debug mode? and as soon you put the code in release mode, your controller will simply return 404 status back? That would be great safeguard if someone accidentally figured out the url to the not-done-but-released-feature.

This can be done easy with an [NoRelease] action filter attribute for the control.

1

As soon you try to access this isolated controller action it simple give you a “404 page not found” page if you try to access it in release mode. And gain full access if in debug mode. Other developers can also access your code it you want them to test something for you. I also made this action filter testable and loosely coupled. Which means you can create your own components that need similar functionality.

Maybe you love the idea of reading a configuration that says “release” or “debug” mode. Maybe you want to use as I do in the code example below; check if a debugger is attached or not.

2

I created my own DebuggingService (you can call it something else off course) that just check if the code runs under Debug Mode if it does it’s just returns and code will be executed as normal. If it runs in other modes like “release” mode it will throw an HttpException with the 404 status.

3

Since I started using this attribute I have had no problem to commit and push my features to the main branch and get it release with the nightly build. I spent less time on branches, merges and other stuff and I could focus on delivery rather than management. This because I love the idea of  low complexity in my source control structure. I know it’s not much, it’s no rocket science but a nice to have feature for a more safe integration and deployment of code in your continues delivery life cycle without spend to much concerns that code got released and spend time to prevent that.

4

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 Big Rewrite” an open discussion at Swenug Gothenburg

Yesterday we had an interesting meeting at the Swedish .net user group Swenug in Gothenburg. The them was “The Big Rewrite”. Instead of allowing a speaker to talk about something interesting we chose this time to make it as a discussion meeting. Two groups in two different rooms had an open discussion regarding the big rewrite.

What’s the biggest problem regarding rewrite an application to new technologies? how can we work to prevent major rewrites? What does the business people in the organization act and so on.

FullSizeRender (4)

Every one agreed that if you need to rewrite something you really need to know what requirements you really need in the new version. To know this you need to measure what features are mostly used today. We need to know if we can change it to better features. We most understand what featured we can delete. We need to understand the ROI of a rewrite.

It’s also important to see a rewrite as a new project not just a rewrite.
Maybe go full agile, use lean startups and so on.

But the most important part is that you can’t just rewrite a product if the whole organization can’t rewrite them self. In other word, it’s not only about write new code you also need the whole organization support to understand what the new rewrite is all about etc… There is no use to take the old backlog and just add new code.

How to make Lean UX with A/B testing fun in ASP .Net MVC? Part 1

A/B testing is jargon for a randomized experiment with two variants, A and B, which are the control and treatment in the controlled experiment. It is a form of statistical hypothesis testing with two variants leading to the technical term, two-sample hypothesis testing, used in the field of statistics.
Source: https://en.wikipedia.org/wiki/A/B_testing

download
And some other nice explanation:  https://vwo.com/ab-testing/

It’s really hard to change or add something and know if it’s a success or a failure before we have test it on real users. In Lean UX it’s important to do this test process as cost effective as possible by decrease unnecessary waste without skipping important work. The best feedback is when you let people use it and see if they like it or not. You can test wireframes, design sketches but that’s not the same as test It for real in real action. Many users will see this cool new thing as a sketch and think; that looks really cool! but is it really that cool when it’s implemented and live in action? Not all the time, maybe some times but we can’t be really sure before we can test it. In Lean UX A/B testing is one approach that can help you get early and rapid feedback if the idea is great or just a new pain for the user. The core idea of Lean UX is to aim small and hopefully shoot big. In other words, do as little as possible and test it before you spend too much time on your ideas.

Let’s see how ASP .Net MVC can make this by just add very little code to make A/B testing fun and easy. 🙂

I love to use the creativity to think; – how can I add something simple that works and also gives me many other possibilities? It’s some kind of evil obsession I have and that’s also what I love most about software design. In this case I will show you how you can add some code to make your page not only A/B test friendly you can use this idea for other things like themes, change layout bases on personalisation and you can even use it to give your user some luxury in e-commerce sites and so on.

In the software, there are thousands of ways to solve the A / B testing. What I found very useful that also decrease waste from more complex solution is to copy the view you want to test to a new location and add changes to that new file, and then let ASP .Net MVC show just that new view based on some business rules. I also want less code, and it shall be easy to remove my test-view without too much work. Therefore, I want to use the view folder and it’s files and not manipulate controllers if not needed. It’s more waste to add new controller if you can use the the you already have when you want to test another layout. My approach doesn’t stop you from A/B test controller as well if you want to add that feature in the future. Remember I’m fan of Agile and Lean approach and principles like KISS (Keep it simple stupid) and YAGNI (you aren’t gonna need it). That’s why I keep things as simple as possible and expand it if more advanced featured is needed later on. 

This is my goal:
Let’s say you want to test your home view, you can then easily add a new folder inside the view folder for example “B Testing” and add your home folder and its view in there. And then add some changes to it… DONE! Cool right? In less of a second you just made a A/B tested home view. Sell it for 5h of work 😉

ab_1a

To make this possible I want to let my view engine look for views in special folders but fallback to the original if there is no files in this special folder. ASP .Net MVC do this by default. Like this setup:

ab_1

I call the variable theme because I can use it for other purpose than just A/B testing too.

Lets create this
Go to your ASP .net MVC project and add a new class that implements the interface IViewEngine from System.Web.Mvc. And implement the view engine code.

ab_2

Then add the folder locations within a method. I call mine CreateThemeRazorViewEngine

ab_3

Then I create a RazorViewEngine and configured the Partials, View and Master locations to the new folder structure of mine. In this case ASP .Net MVC razor will act as normal but start looking for files in my theme folders if they exist.

I love the factory and provider pattern so I will use those. As factory I will use DI/IOC framework, I like Autofac but you can use whatever you like the idea is the same.

I start by creating one IViewThemeManager interface with one method GetTheme. This interface is the one we use on all the ViewManager providers that will handle all the business rules based on why you want ASP .Net MVC call for another view or partial.

ab_3a

And then I implementation my factory method to the ViewEngine with the IOC and some error handling.

ab_4

If there is no IViewThemeManager provider configured it will give me null and return the default Razor view engine. That’s why I use the _fallbackViewEngine. If there is an IViewThemeManager provider registered I ask for the Theme which in this case is the folder name I want the view engine to use.

After that we need to tell ASP .Net MVC what Engine it shall use so we need to add some code for the methods implemented from IViewEngine

ab_5

In this case I call my CreateViewEngine that will return either the default engine or mine.

Here is the full file:
ab_6

Now go to Global.asax and clear all View Engines and add this new one in Application start.

ab_7

We can now run the project and everything will work as normal. This because the resolver can’t find any IViewThemeManager provider yet and fall back to default.

ab_8

Now it’s time to add the A/B testing business rules. In this case I want to know if the “Learn More >>” button gets more clicks with another text. So I want some user to get “Learn more >>” and others “Want to learn more?”

First I copy the index file in my home folder to a new home folder under “B-Testing” and just change the text on the button nothing more.

ab_9

ab_1a

Then I create my IViewThemeManager provider. My ABTestingViewThemeManager.

ab_10

After that I will add some simple rule. In this case I just send them to my “B-Testing” view folder if the date time second contains number 2. (Just for the test, ok? Real A/B testing might need more complex logic and maybe even som settings, depends on how important the function is, remember don’t make it to complex if not needed. KISS 🙂 )

ab_11

After that I configure my interface and provider with autofac.

builder.RegisterType<ABTestingViewThemeManager>()
.As<IViewThemeManager>()
.InstancePerRequest();

And when I run the page and if the DateTime.Now.Second contains number 2  it will use my B-Testing view instead.

ab_13 ab_12

I also added the view rules for partials so you can just test a partial as well if you want to, you don’t need a full view, you can use the default one that just calls for your partials.

Just copy your A/B partial to “B-Testing/<your controller folder>” and this code will take care of that too.

And if you use partials to render templates for example angular you can even test unique directives and web components if you want to. Just add the angular template in your partial and copy just that partial and its folder structure to the “B-Testing” folder or what name you prefer.

You can also add a provider that will give some user a whole new view, layout or webcomponents layout if they are lets say “pro users”. Just add a pro user folder and create a new IViewThemeManager provider that check if the user is of the role pro or something like that.

Happy play around.

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