NDC 2017 - this is what I saw

Higlights - are marked in italic                       #NDCOSLO

Wednesday

• Key note, Dylan Beattie
• Mathew Mcloughlin, Thinking in events
• Damian Edwards and David Fowler, What's new in ASP.NET Core 2.0
• Udi Dahan, Microservices and rule engines - a blast from the past
• Sam Newman, Feature branches and toggles in a post-github world
• Jon Skeet, C# 7
• Steve Anderson, ASP.NET Core for Angular, React and Knockout developers

Thursday

• Dina Goldsthein, ETW - Monitor anything, anytime, anywhere
• Reginald Braithwaite, First class commands - the 2017 edition
• Overflow - Todd Gardner, The developers guide to promoting their work
• Steve Sanderson, Web apps can't really to "that" can they
• James Lewis, Betting on performance. A note on hypothesis-driven performance testing
• James Lewis, Microservices and the inverse Conway manoeuvre
• Nicole Saidy, Designing great progressive web apps

Friday

• Troy Hunt, Hack your career
• Hans Peeters and Benny Michielsen, The blockchain what, why and how
• Lightning talks -
• React native
• SVGs for powerpoints
• Vue.js
• Css animations
• Overflow - Rob Conery, Building a serverless api with google firebase and postgresql
• Overflow - Jimmy Bogard, Compositional UIs - the microservices laste mile

Summary (tbc)....

• Web apps -
• progressive apps
• service workers
• offline support
• new apis and browser functionality
• Scalable architecture and team setup (microservices).
• cross functional teams
• architect for stable business areas
• requirements - think events (workshop ref. Mathew M.)
• Entrepreneurship.

Development projects 101

Introduction

Projects are all about delivering software to the users. But how can you assure the right quality? How can you involve the correct people? How can you deliver on time or cost? Why are these challenges so hard?
Here's a short reminder or summary of some practises I've had success with.

Build a small team of super people

You need a small team to start the process. They do not need to be involved full time, but they should be dedicated to the project, so that anything related to the project should have full attention when needed.
Project leader, super user, developer, designer, tester. You should all be involved and ready.

1. Get to know the problem domain!

Involve the users and make friends. This makes sure you deliver the right thing (and not just deliver things right). Get examples and experience real practise.

2. Ship as fast as possible 

Automate the deployment pipeline. Ship as little as possible to minimize risk. A calculator that only returns 0 is still a calculator. Not particularly useful, but it's still something that works and can be tested/viewed.

3. Test and iterate

At any iteration you should be able to go to production dependent on the deadlines.

1. Get the core functionality up and running
1. What constraints are there?
2. How to solve the problem as easy as possible?
2. Get user feedback
1. Does the basic functionality solve the problem?
3. Get experience 
1. Can the flow be better?
4. Iterate and refine usability

This enables a good feedback loop. And you make sure to deliver on time.

4. Make sure you plan for flexibility

Say no. Can it be differed? Always prioritize the most important things. Usually some minor changes can be done later, and the user can live with a workaround until then.

5. Involve all stakeholders

System development is also about changing people and the organization. User training and involvment from the business side are important.

Some general considerations

In Rework they talk about four letter words: need, must, can't, easy, just, only, fast. Who hasn't heard those words in a project. The problem, as the authors also say, these words introduce a black/white situation. Implying that the work being done is a minor thing. This is a fall trap and I will say it's in the category "assumption is the mother of all fuckups".

Summary

It's a hard practice, but a good team and dedicated people makes good quality solutions.
So don't have FEAR (False Evidence Appearing Real), www.agilemanifesto.org.

Don't be a legacy coder!

I have had some time recently to read up on several topics. Now I am reading "Testable Javascript" by Mark Ethan Trostler. In the introduction of the book he is talking about legacy code and the consequences that has for the code owner and application.
I think the legacy code description in the book was so good that I want to quote parts of the introduction directly. I encourage you to buy and read the whole book. Legacy code is not much debated any more, but that does not mean the issue is solved. Read and act:

"What is legacy code? I’m a fan of Michael Feathers’s definition in his excellent book,

Working Effectively with Legacy Code (Prentice Hall): legacy code is code without tests.

This code either will not survive or will never be touched by anyone. When the time

comes to touch legacy code, it gets rewritten. Take a look at your current project; any

code that does not have tests will likely be rewritten. Probably not by the author of the

code, but by whoever is now tasked with dealing with it—either enhancing or bug-fixing

it. Unless tests are written, this is dead code that will have to be rewritten. The code may

be spectacular, but the only way it will survive is if it never causes bugs and if no one

ever requests enhancements or new features for it. Even then, how happy are you to ship

production code with no tests? Even if the code “worked” before, are you content to

keep rolling the dice? Is your company, which owns the code, content to keep rolling

the dice? Typically the piper must be paid, and this code will just get rewritten. It’s too

bad the company had to pay to have this possibly spectacular code written twice, but

such is the case with legacy code.

As you can see in the matrix shown in Figure P-1, it is very easy for any legacy code

you’ve written to fall into someone else’s hands and be rewritten. That path is typically

less painful than bringing someone else’s legacy code up to speed with tests. It is very

easy to move from side to side in this matrix, as code changes hands constantly, moving

into and out of your purview with great agility. Moving “down” is the hardest path for

code to take; writing tests for existing code is a job no one wants to do, and most people

will go to impressively great lengths to avoid it—typically resulting in a complete rewrite.

Unfortunately, moving up in this matrix happens with some regularity. Code that starts

out with tests can lapse into legacy code if it falls into the wrong hands. Vigilance is

required to keep tests up to date as more enhancements and features are bolted on, but

this is a much simpler process than writing tests for code without any (or with very few)

tests."

Code contracts in C# - yes?

There isn't t much talk about C# code contracts, introduced in .NET 4 (as I can remember). Why?

Jon Skeet mentions it in his latest C# book, and he has good expectations  And it goes hand in hand with a test-driven style of coding. Which is what I believe developers still strive to do.

It would be nice to have contracts:

• in your NuGet packages
• in legacy code
• when writing new tests
• for documentation
• for logging precise error information
• ...

Read about Code contract here - http://msdn.microsoft.com/en-us/library/dd264808.aspx

Steps and principles in requirement specification

Principles:

• Vision - share the same vision
• Users - must participate
• Work practice - must be experienced
• Anchor - desicions

4 phases:

• Creation - of project
• Strategy - to implement
• Depth - to dig for needs
• Vision - to renew

6 elements of a decision-process:

• It is a generic problem and can only be solved by establishing a rule, a principle
• What are the boundary conditions, which must be satisfied
• What is right (not just acceptable)
• What compromises must be made
• What action must be taken to carry it out
• What feedback can test the validity of the decision

These are just some reminders of important artefacts during requirements digging.

User centric development

"All a computer can handle are abstractions. And abstractions can be relied on only if they are constantly checked against the concrete. Otherwise, they are certain to fail", Peter F. Drucker.

I think this quote says all about why you should constantly research the user.

Kafka - TDD - And a course in TDD with Roy Osherove

I just finished a 3-day TDD course with Roy Osherove. Here are some of my lessons.

"The right understanding of any matter and a misunderstanding of the same matter do not wholly exclude each other", Kafka. That is one of the ultimate issues with software development, and TDD helps addressing it. How?

The simple rules for TDD are:

1. Write a test that fails.
2. Make the test pass.
3. Refactor.

By following these rules I will also do:

• Investigate the problem domain, but not more than necessary, and make sure the assumptions are right.
• Implement code that works.
• Implement the right code.
• Start with a simple thing, that can be finished within short time, at least within a sprint.
• The development cycle will have small incremental changes, rather than larger code chunks which is harder to test.
• Decide when to do state-based testing and when to do interaction-testing.
• Do test reviews.

Other things I will do:

• Address legacy code with TDD.
• Consider not doing TDD, but right now TDD feels simpler than not doing TDD. Even though TDD is hard.
• Separate unit tests and integration tests.
• Do pair programming.
• Write more integration tests.
• Start learning code contracts (C# 4.0).
• Start learning specification by example and write acceptance tests.
• When I have made a new system, or learned a legacy system, I will make a video describing it
• Write down the coding conventions.

Other things I learned from Roy:

• How to learn things, and what ravines and plateaus are. (This is a part I feel need even more investigation, but not now.)
• Go mouse-less.
• Do coding katas for training. (I have already been doing this after the course, and will continue).

So TDD addresses the understanding/misunderstanding of issues by forcing you to make assumptions and implement the right code. Make it your choice to do it!