Filed under: Programming, — Tags: Easy to test, Easy to use, Simple — Thomas Sundberg — 2014-11-30
I came across this tweet the other day:
"Novice engineers have not yet grokked this: the number of modes or options in your system is the *exponent* in how hard it is to maintain." by @zooko.
This is very true. The more options a system has, the harder it is to understand, maintain and use. This is one of the reasons why I usually always try to hard code things like parameters to scripts in my first iteration.
Hard coding is something that some of my colleagues sometimes have a hard time to accept. It happens that the argument is "I don't like hardcoded things". I can understand that point of view and I extract parameters when I have got one use case working with a hard coded solution. But I don't do it before I have something working.
I think the same apply when you implement anything. You start out building something that isn't generic. A less generic solution, or hardcoded solution, if you want. You make it work and verify that it is possible to use in the intended environment. Then, and not earlier, it is time to generalise and possibly extend it. If you have implemented it with a good set of tests, they secure that the specific use case isn't broken while you refactor your implementation to a generic solution.
I spoke to a manager at Spotify a while ago. He said that the hardware guys there had been forced to work with at least one team before they where allowed to create a new, fantastic solution. Why? If they worked with one team, then they had at least one customer. I was told that there had been a history of hardware solutions that were more or less brilliant but never used. The users that the engineers thought would use it didn't understand or didn't care because they didn't need the brilliant solution.
I have seen similar behaviour at clients. Good solutions are built but the selling part of the job is not done properly. The result is that nobody knows, understands or possibly even cares about the great solution. The result is waste.
I have also experienced the inverse. Management have seen a demo of a tool and decided that this must be the best thing since pre-sliced bread and forced it onto the guys who actually does the job. The result? Not so great. People get frustrated and the joy of doing a good job is gone when you are forced to use a bad tool.
So, connecting back to the tweet, make sure that you have at least one customer before you make your tool generalised and parametrized so you can get valid feedback on what actually is needed. Don't assume things, try them on real users.
I found another tweet connecting to this subject, don't solve hypothetical problems. An actual problem is a lot better to solve than a hypothetical problem.
It is often better to build a specific solution instead of a generic solution that has many options that must be set properly. It is easier to use and it is easier to test. The specialized solution is usually better at solving the problem compared to a generic solution. It is like comparing a chefs knife with a Swiss army knife. The Swiss army knife is ok on many things, but not great at any. A chefs knife is useless in most cases, but perfect in some.
Remember the words of Albert Einstein. "Everything should be made as simple as possible, but not simpler."
RSS