All the wrong tools
Hey there, my dear beloved reader!
I have a strange, but very important question for you — have you ever tried to hammer a nail with a screwdriver? Not since you didn’t have no hammer but because you didn’t know which tool is used for hammering?
With the best trust into humanity, I assume that the question to the answer above is “No”. We don’t brush teeth with soap, we don’t wash our clothes in a microwave and we don’t do a lot of other weird, and sometimes dangerous things. Yet some of us use MongoDB for relational data, and try to implement graphically intensive games using JS game engines. Or implementing a design pattern in the way that is so “tailored” to serve our needs so it has very few things left from the original idea, and doesn’t really work well. There is no doubt that the pattern is to blame!
Yep, today I would like to talk to you about how people may sometime make very odd decisions when it comes to selecting a technology for their project. A small note before I begin — I am going to use words “tool” and “technology” as universal keywords for many different things such as design patterns, programming languages, IaaS platforms, Agile methodologies etc. Everything written below can be equally applied to all these “tools” and “technologies”.
So you are starting with a new shiny project, which you are sure shan’t be implemented with that tried-and-true tech you already have in your toolset. I will assume that you have some legit reasons to do so (e.g. you read about this in your favourite blog on Medium), and get a closer look at two problems with wrong tools.
Problem I: Totally wrong tool
The problem
Whatever tool you are going to use is made for anything but what you are about to do. Of course it may be well fit for few other things, none of which you will try to do in your lifetime. Or it may solve exactly one problem encountered by its creator ecxactly once. The point is — it will not help you in any way and may make things very complicated in the future.
The other day I read a story which was called something like “Let me tell you about a way we’ve realized that MongoDB actually sucks big way!”. I may be exaggerating but the whole idea, and a title of that read were being something very similar to that. I’ve never used MongoDB in my entire life (at least prior the moment this text has been written) but I’ve definitely heard that it doesn’t suck, and can be very helpful in some situation. Nevertheless, that article was about a group of people who were working on a social network project of a sort. I won’t tell you the whole story, but at some point this group of people have suddenly realised that word “network” assumes some nodes, and those nodes are connected to each other. These nodes’ connections make them related to each other on so many levels. That kinda means that nodes have relatioships. However, unfortunately for MongoDB, relationships is not a concept that really exists in this document DB’s universe. Shame on you Mongo! You Suck!
I am telling this story sometimes, just to illustrate the idea, and not to make fun of people, who have learnt their lesson, and have been brave enough to write an article about this. Bold move, point taken, all good. What really surprised me about that situation is that the team of experienced developers so reclessly decided to use an unknown technology in a big production projects without having complete understanding of what it was actually made for. As well as a fact that one of them became so upset about their choice, so instead of admitting a mistake early and fixing it, actually decided to build some weird workarounds until the whole thing started to fall apart. And then she blamed the tool. I also heard similar stories about people trying to use Elastic search as a database or SSIS packages as a backend for web applications.
How to avoid it?
Obviously, conduct some research on both — a tool you have on your mind an a task at hand. This can be simultaneously approached from two opposite directions:
- What kind of problem are people trying to solve when they discuss the tools you’ve heard about;
- Which tools are people normally using to solve the problem that you have.
It may seems that option two should be enough but I’ll give you a couple of good reasons, why I think option one is necessary. First, it opens possibilities, and helps you explore trends that are not too mainstream but may be worth to be considered in the nearest future. Secondly, it can also help you to assess your ability to understand technologies. What I mean is – if you’ve decided to read some articles about the best practices of programming iOS games with COBOL.Net and you’ve found none, then this may be a good indicator that you lack understanding of either COBOL or iOS development. Or both. Definitely both.
However, back to the point. Once you perform that two searches mentioned above, you can find overlap of technologies/tools/practices that are often mentioned in both. This is exactly the stuff you want to mess with in context of solving your problem. There will always be more than one way to tackle it though, so just use one you are more familiar with, or one that is backed by a big (HUGE!) IT company that is known to use it in their main products, or just pick one with the coolest name. NinjaUnicornPajamarizer.io.
Quite importantly — be serious about your tools. Just like your project should add value to your business, your development process should benefit from your tools short to medium term. ‘Cause in long term there will always be another popular JS framework or Agile methodology or whatever.
Problem II: Right tool goes wild
The problem
This thing is way more dangerous and tricky then simply picking a wrong tool. This is about picking a no-tool-at-all with full confidence that this is a right tool, that it is supposed to help, and which just doesn’t work in your case. Troubles are doubled if other people – naive colleagues or juniors – trust your judgements and start confusing a real thing to someone’s broken perception of it.
To give a bizarre example – imagine you know that using a hammer on screws is a bad idea, so you get a new shiny tool – A Screwdriver. The problem is you’ve taken a plastic toy screwdriver, which you’ve covered in oil to make it shiny an glossy and attached a one kg slab of metal to the tip to make it look and weight as a hammer. Then you’ve started hammering a screw with the bottom side. Lot’s of fun, zero of results, and sore disappointment caused by the fact that all of the people on the internet don’t understand your company’s unique nature, and suggest a rubbish thing instead of an ol’ good hammer. Jeremy Clarkson for example can fix everything with a hammer.
To identify that you actually have this problem is quite easy – something that works miracles for 99.9999999% of businesses similar to yours seems absolutely useless when you try to use it.
I have a couple of good examples for you!
First is a guy I’ve had a chat with about his experience with Scrum. He used to be a manager or a director of a sort in a small IT company in Russia (which is a medium-sized company by NZ standards). He said he didn’t really like scrum nor did he see any value in using it over XP or even waterfall in his company. I asked him which part of the process he didn’t like so he told me about how they used to work. In their organisation the product owner’s role was shared among stakeholders, some managers acted as scrum masters and gave estimates on backlog items, and lots of other odd activities were going on. None of this sounded like Scrum to which I pointed out. “I know.” – he said. – “That was because we tried to adopt Scrum to our environment.”
Second story is about a rather nice conference talk dedicated to CQRS. Despite being an overall enjoyable and valid it raised one point that I couldn’t agree with. The speaker started with criticism of controller-service-repository approach in Web development. His main argument was that quite often developers implement services that simply mirror functionality of the corresponding repositories – meaning each repository method has an identically named service method which it is being called from. Needless to say that this repositories are huge and services are useless and make almost no sense indeed. Here is an example of such architecture:
I maybe a little bit exaggerating here again, and the service in the talk I am referencing does have a little bit extra on top — e.g. it operates on DTOs, not DB models. However isn’t it a much better solution to reduce amount of methods in each repository to six by replacing all GetBy* methods by a complex Search() method? So repository can look more like its description on Wikipedia?
Shall we blame a pattern for developers that are sometimes too lazy to write complicated and future proof code to properly implement it?
How to avoid it?
The idea I am about to share may be something wrong, and weird, and dangerous but I believe this is how thing gotta be done. Here it is — follow instructions to the letter. At your first attempt of working with a new technology or process or programming language start with the very basics and try to implement all the good practices.
At some point you may find it very tempting to start “bending” the tool the way so it fits paradigms you’re familiar with. E.g. you start assigning PO responsibilities to stakeholders in scrum, return huge data sets as a response to command execution in CQRS or implementing super thick repositories. From my experience such actions often mean one simple, and sad fact — you do not quite understand what you are dealing with. Frankly — if at some point you realise that the way you use a certain tool has little in common with what its author says about it, then you should take a few steps back to find a moment when everything went wrong, and try to start following whatever instructions/guides/good practices you could find as closely as possible. Otherwise you may be in a situation where you believe that you have something but in reality this is something completely different. What you see as a shiny unicorn in reality is an ugly chimera that has nothing in common with a noble beast your spell book describes.
The problem with the new stuff is that sometimes it is too new, and we are too used to our old ways of doing something. No matter what new toy you’ve decided to bring to your playground, accept the fact that it may require you to leave your comfort zone for a while, and change your mentality before you can start palying with it. Provided what you want is joy caused by a nice game not pain, and misery, and desire to throw this rubbish into a bin ASAP. Not that I judge mazochism, but I don’t really know how to help you if this is what you seek.
However back to the point. New ways will requite certain shift in mentality, and you must accept this fact. This may be a slight change such as moving from Kanban to Scrum, or as brain twisting as attempts to migrate your libraries from C# to F# (or Java to Haskel). And this shift should come before you actually start using a new tool on a daily basis.
The only exercise I may suggest, which will help your ability to see the world from the angle required by the new tool is to start a pet project. Playing around with it at the time when your brain is not occupied by your day work’s tasks, and troubles will help you to get some traction and obtain necessary skills and knowledge. Later on you will be able to scale all of this for bigger production problems. In simpler words — make sure you can walk before you run. Implement a new TODO list app (or a JS framework) for every new tool you want to use if you don’t know where to start.
Conclusion
Always choose a right tool for a job and use it properly! Also eat well and sleep at least seven hours.
On a serious note — everything above is a compilation of lessons learned from valuable mistakes made by me, and/or people I met. It is always tricky to start doing things differently to how we’ve used to do them, and a nasty bit is that we sometimes can’t say if we are doing something incorrectly. So make absolutely sure that this new way is the one that will lead you to the outcomes you are after. And then make sure that you are following this path, and not trying to take shortcuts that may end up in a bottomless bog of regrets instead.
