/ product

Getting a Feature From Console to Production

Recently, I noticed a lot of features in Angry Building have the following pattern:

  1. I go to the Rails console in production and do some operation
  2. I copy the code, which I executed in the Rails console, into a file wrapped in a function, which I can copy/paste into the console.
  3. Move the function into a service object in the main codebase, cover it with tests, and handle all edge cases.
  4. Wrap service object with form object and expose it with web form only to admin users
  5. Expose the form to users - this operation was battle-tested by this time, and we know all of it has implications.

Example

One example of such a feature is our change of payment's apartment.

In Angry Building, we track tax payments made by the apartment to the facility.

We allow importing payments from bank transfers, where we create payment records for apartments based on bank transfers.

For some transactions, we determine which apartment has made the payment. Then an operator can assign the apartment manually. Mistakes can happen here, and we need to re-assign the apartment.

Over time, as we get more customers using this feature, we get more requests for change payment apartments.

So change the payment apartment feature following the 1 -> 5 steps to be implemented.

Discussion

Now, I know what you are thinking - Why don't you just go to the 4 or 5 (implement in UI) steps, why spread work around? ?

Some features go to the 4 or 5 steps directly. It is a judgment call.

If I had to implement UI and expose everything I had to do in the console, my software would be bloated, and I would need a bigger team.

Many "features" fizzle out in steps 1 or 2 (execute directly in the production console) are caused by bugs or confusing UI.

When I get a request that requires me to go to the console - I try to do a root cause analysis to see how to prevent this. I have increased the overall system quality so much because of this.

When we reach step 3 (move to code as service object covered by tests), the threshold to become "a real" feature is passed. Then moving to step 4/5 is more about work priority and how dangerous it is to expose this feature to everyone.

Then is more about how often we get the request to call this service object.

The features implemented this way are based on support requests. Not all features go through those steps.

If you have any questions or comments, you can ping me on LinkedIn, Mastodon or Twitter.