Saturday, May 5, 2018

Bezos' 'Work Life Circle' Out of Touch

Before I enumerate the comments that Bezos makes that show that he is out of touch with the majority of his workforce, I would like to point out that the overall goal that he shoots for is what everyone should strive for. "If I am happy at home, I come into the office with tremendous energy. And if I am happy at work, I come home with tremendous energy." And ultimately, that's what people are trying to ensure when the ask about work life balance. They want to know if they will have the time to be happy at both work and home so that one does not negatively affect the other.

At a high level, the examples he gives that show how he lives are well beyond the means that most people have available in terms of both time and money. Going on an amazing birthday trip with the kids to Norway for three days to stay in an ice hotel, go dogsledding and a wolf preserve; liquidating $1 billion and the time necessary to set up Blue Origin; even just having breakfast every day with your family are not things that everyone can do for one reason or another.

Bezos' comment of work-life balance being 'a debilitating phrase because it implies there's a strict trade-off' is inaccurate and/or left unexplained. Unless the only enjoyment in your life occurs at work, you have to sacrifice time at one to get time for the other. The best point that he could make here is that the act of balancing the time should come naturally. And that would truly be great. Unfortunately, as further points illustrate, that is easier said than done for people.

Setting aside some powerful, and arguably sappy, cultural messages and mores that promote putting life and family before business, many people have goals they want to achieve in their lives other than making a rich boss richer. Work is necessary to pay the bills, and that takes time away from these other goals. Without clearly defined boundaries, it is too easy for even altruistic bosses who only think they're encouraging a better life, to take away the things that bring one pleasure in life and work.

Now, let's look at the idea that the demands on one's time outside of work tend to increase the less privileged you are. It's great that Jeff  "sets aside a few minutes every day to wash his own dishes." Does he mow his own lawn? Clean the rest of the house? Fix his own car? Plan his own vacations. Take his kids to school, to the doctor? Help them with homework? Make their lunches? The answer to some of those is probably yes, but I doubt it's less than most people. How many chores does his privilege buy his way out of that then allows him the extra time to bring his work and life into harmony?

It's great when you control your own schedule such that you can eat breakfast with your family every day. That doesn't work so well for people that have to take phone calls from 1AM - 9AM with even moderately regulated break and lunch times. Nor does it work for people that can't afford to live close to work, must commute for hours a day, and have responsibilities that don't allow them to work even when they're lucky enough to be able to take public transportation.

Again, work-life harmony is good. But there are necessarily different ways of accomplishing that depending on what your goals and means are. Disparaging one approach as detrimental or toxic comes off as, at best, naive of the conditions in which most people live and work, and at worst looking down on the career and life goals of others.

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.

Wednesday, March 21, 2018

Comment Your Code

Most code is for developers, not for computers. Computers have always been perfectly capable of reading long streams of ones and zeros, performing work on those stream, then spitting out results as new streams of ones and zeros. Sure, computers have gotten faster since those streams were stored exclusively on paper punch cards. And sure, we now have new ways of providing input and receiving results. But, most computers still operate in the same fundamental way. Computers don't need C#, Ruby, JavaScript, SQL, JSON, compilers, interpreters, monitors, keyboards, mice or VR. People and developers do.

Most developers don't garner any meaning from reading a bunch of ones and zeros. Most people need abstractions in order to understand any significantly complex idea. And, people make more assumptions than they realize. These and similar human failings are why the vast majority of software language features exist.

To get around the lack of understanding of binary information, developers use higher level, abstract languages to create software. A good number of developers think their code is perfectly readable on its own. Even if that were the case, the only way to prevent others from making incorrect assumptions is to provide more context than the method calls themselves. This means commenting your code in plain [language of your choice] to describe the responsibility of each member.

Similar to how unit tests provide a second set of code to ensure correctness, providing another description in addition to the code itself will help prevent misunderstandings about how to use and maintain your code. Some people go so far as to claim that unit tests are an adequate replacement for comments. Bollocks. If your code doesn't take advantage of the popup guidance that intelligent code completion tools (IntelliSense to us Visual Studio fans) provide to instruct others on correct usage, you're not using the best tool available.

Other developers claim that commenting code takes too much time. But if an engineer can't type a description of the responsibility of a class, interface, property or method in under a 15 seconds, they either don't understand its responsibilities or they need to learn to type faster. Either is a deficiency in any engineer's professional skill set. Those extra seconds of typing may add up, but they are a tiny percentage of the time that should already be spent on designing, writing and testing that code. That time is also miniscule compared to the amount of time that will be prevented maintaining the documented code and fixing bugs when uncommented code is inevitably misused.

Thursday, November 18, 2010

Development Database Setup

Hello Everyone,

If you're working on an application of any significant complexity, one of the tasks developers must deal with are database set up scripts.  One trend that I've noticed over the years is that projects where developers maintain a set of scripts that setup the databases from scratch tend to go more smoothly.  To be clear, this process includes tearing down any existing database, rebuilding the database to the most recent release version, loading good test data, and finally running all change scripts for the next release.  Though those last two steps can be reversible depending on the project.

Example the first.  I have a system.  Yaay!  I need to make a change to the database.  It's a relatively complex change involving creating a new table including keys and indexes, copying data from an existing table to the new one, and removing columns on the old table. Booo!  After I make all these changes and have the scripts in place, I need to test that I did everything correctly.  On the plus side, I have a thorough rebuild process in place.  I can click a button and the whole system is rebuilt, I find problems and fix them myself and I know without bothering any other developers that the scripts are good.  Yaay!

Example the second.  I have a system.  Yaay!  I need to make a change to the database.  It's a relatively complex... yada yada yada... I need to test that I did everything correctly  Booo! Unfortunately, databases are not torn down and rebuilt as part of the setup process, they are only modified.  What do I do to easily test my script.  I can undo the changes by hand and rerun the scripts to make sure, or I can check in the changes, hope for the best and let the next developer find any problems and repeat the cycle with yet another developer.  Which one do you think ends up happening more often?  Booo!

This may not be a huge issue that comes up a lot, but when I see emails going out a few times a month with issues lasting a couple of days because things are done the latter, it reminds me of how many things that developers already need to keep track of and this is just another disturbance.  In the end the amount of work to make the changes is the same, but having a complete rebuild is a way to minimize disturbances and keep developers developing.  

If starting a new project, I highly recommend the complete rebuild approach because the hardest possible task would be overcoming momentum and switching from one process to the other.