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.

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

 

 

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

 

 

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