Page 2 of 2

About those “would be nice if…”s

New project. We have our meetings, we come up with a plan, we somehow agree to a budget and then we get the ball rolling, coding our way to the finish line.

As we build stuff, fresh requirements are sent in. “We need this new feature”, “we haven’t thought of that”, “it would be nice if…”, etc. And it’s ok. We saw this coming.

Displaying that list on two columns, making those elements editable, changing that color, size, font, whatever — they seem to have such a low value that we often neglect them. But they pile up and sometimes affect the system in ways you wouldn’t expect, taking an even bigger dip in the budget.

We are bad estimators. But that’s not the worst part. The worst part is that we rarely, if ever, say no to a client.  One reason, apart from the customer is always right and make the client happy, is that it would make us feel incapable, unworthy of our profession. We take saying no as something to be embarrassed of. It’s not.

Saying no not only leaves you with fewer things to do but also leads to a major increase in productivity. It’s far easier to stay focused when you don’t have to worry about the “would be nice if”s.

The devil’s in the details. Control the scope.
Focus on what is essential to create value now. Add the rest later.

Deptory intro

Automated tests give us the speed and confidence we need to make quick changes without having to constantly check the thing we’re working on. They improve our code, make finding bugs easier, provide documentation and help us save money in the long run.

But automated tests are not enough to ship quality software. They focus on the happy path and don’t do much for the unknown scenarios. They cannot be compared to an actual human being going through the app, using it in all the ways a real user might.

Before deploying a project or a new feature to production, I split every screen into small components and describe how they work. I do that by writing checklists. Components are forms, buttons, lists, list items, whatever I can think of having its own set of actions.

I then go through each checklist and try to reveal any unwanted behavior. I simulate slow networks, click and drag things around, submit forms multiple times, make different actions on things no longer exist, etc. I do my best to go off the happy path and break the system.

It’s not only about finding the bugs. By disconnecting and using the software myself, I discover new ways to make it better. I can clear my head and look to improve things – both code and design wise.

Compiling those checklists takes a lot of time and effort. And if you write them on paper as I do, they’re gone as soon as your code hits production. I’d love having a place to keep them.

Work at the smallest scale possible

You know that feeling when you found an elegant solution to a problem you’ve been having? You discovered that pattern you’ve been missing and you’re like “yeah! now I get it!”.

The excitement gets the worst of us and we start acting like the thing we found is the holy grail of software writing.

Like yes, this looks way better. If I apply this pattern here and use this structure there, all my problems go away. And we sprinkle all that over our project.

A few days go by and we’re like “wait a minute…this solves my problem but complicates this other thing I’m working on. Fuck..”.

We fiddle around with it for a few hours, sometimes days, and then we either find a way to patch things up or we hit the undo button and start from scratch.

The thing we found has its use. Where we go wrong is trying to force use it everywhere.

Hello world!

I read, watch and listen every day.
I have trouble remembering things – it’s time to write stuff down.

© 2018 cdruc

Theme by Anders NorénUp ↑