Thursday, April 19, 2018

Being More Agile

The slow growing product team at Milyli is currently making the transition to full agile. For the most part, this has been a smooth process. As owners, we believe in agile and trust that the team will do their best to get to the features as fast as they can and that by having less process we will be getting more features at higher quality faster. No one asks, 'Yeah, but what features will be delivered eight sprints from now?'

The hardest adjustment has been for developers. As engineers that believe in delivering quality that have been working in a more waterfally environment, mostly due to demands of customers in a very traditional market, it can be difficult to say that a story is done when the UI is just an ugly row of numbers. Even when that data proves the system is doing what it's supposed to.

It's important to remind the team that an ugly UI is OK. The team wrote the code that implemented the feature as designed. The feature has a full suite of automatic tests, unit, integration and UI when feasible and applicable. We could deliver that story if necessary or desirable for some reason. 

We didn't polish the UI because we wanted the stakeholders to validate the behavior and maybe give some ideas for the UI now that there's a straw man to look at. If we had also completed the UI and the behavior was wrong, we'd likely need to redo the UI as well. 

We will polish the UI in the next iteration. It might not be perfect even then. It might not be perfect before the users see it. But we can get feedback fast, act on it immediately, and have a fully tested deliverable ready in no more than two weeks time.

And that's what agile is about.

Sunday, April 8, 2018

Unit Tests and SOLID Code

One of the realizations that we had at our office over the past few years is that SOLID code is easier to unit test. If code is easier to unit test, we will have a higher level of unit test coverage. So a high unit test coverage number is decent indicator that our code follows the SOLID principles. Not foolproof, but decent.

Tests taking too long to write because you need to mock too many dependencies? You're code is probably doing too much and you're not following the Single Responsibility principle.

Tests taking too long to write because you have to factor in too many cases from base classes? You're code is doing too much because you're not following the Open Closed principle.

Tests taking too long to write because you need to test too many exceptional states? You might be adding too many exceptions to sub-classes by possibly ignoring the Liskov Substitution principle.

Too many tests needed to cover a class effectively? Follow the Interface Segregation principle and have more classes that do fewer things.

Can't inject mocks into your tests easily? You really messed up that Dependency Inversion part of SOLID.

Not sure how universal this is, but it seems to hold for quite a few architectural styles. As always, this is my 2¢. You're mileage may vary.