Discussing Architecture

July 10, 2016

I want this blog to be very technical but as with all things, in this line of work, you have to deal with people at least as much as yuo do with the tech.

When I was in college, back in the 2000’s, I had one class that was very hard because it was hands-on, practical and at the time it just was not something I was used to. The goal of the class was to teach us how to properly measure things and compare materials (metallurgy). I was studying production engineering and those classes were necessary intro for that program.

The teacher was a really colorful character. From the start you could tell he was very into the subject. We later learned that he spend a lot of time tinkering with some of the CNC and older machines. He also lost one of his fingers during one of his experiments and in a strange way was very proud of that.

Anyway I struggled with the class from day 1 and it was very stressful experience for me but there’s one thing I learned there that still helps me make decisions as software engineer to this day.

I don’t think it’s a secret but I do think that at some point (preferably early in your career) you should take time to realize how important this is. During one of the first classes the teacher asked us:

Why are we here? What are we trying to learn that is so important?

I thought the goal was to learn the basics the vocabulary but the teacher insisted there’s something more profound going on. We went on with the class material, and after we were done he asked us again but no one was ready to answer.

The job we are training for here, that of an engineer, has one overarching rule one criterium that you have to be always mindful of. Today we learned about measuring […] but why did we do it? Why don’t we build bridges and buildings out of titanium instead of steel? The answer is that steel is good enough but cheaper. Price is easy to understand but what does it mean that it’s good enough? It means it’s stronger than X it’s flexible enough…. [..]

Going back to original rule I mentioned, engineering is about trade-offs most if not all technical decisions you will make will have both pros and cons, and if you don’t know both of those it means you are not making an engineering decision you are either lazy or guessing.

I often come back to that class… I forget the stressfulness of it but I remember how often it happened that I came back to those words. As software engineers we as well should make decisions based on tradeoffs but that is something that does not happen that often… Have you ever seen this in your work?:

• In response to a problem with one of the systems, someone says: “we should have developed it in X”
• People using a kind of mental shortcuts saying things like: “We need to use Redis here”, when they mean that some part of computation needs to be cached
• Someone mentioning some new tech she/he is learning about and than somehow that tech comes up as the way to solve a problem the company is having

Are those bad things or antipatterns? Not necesairly, but let me ask you this: if you would be working on building a skyscraper, would it be OK for someone to waltz in during a meeting and say: “We totally need to use this new construction element I’ve just read about on BuilderNews last week, the guys building in downtown SF are all using it”?

Discussing Microservices

One fad that seems to be phasing out these days is starting every project as microservice. Let us talk about that for a moment. Microservices.. should we use them? Should we rewrite every web application into microservices? Should we start with them as default architecture? If you feel you have too little context to answer this question that’s great, but have you ever wondered just how much context do you need to do that? There is only ONE correct answer to questions like that, and it always is: “It depends”

• It depends on the project size.
• It depends on team skill level.
• It depends on our goals.
• It depends on thousands other things.

If you think about it, when you face a technical or architectural decisions you should almost always be mindful of the tradeoffs. It’s somewhat silly that I have to put simple things like that in writing but the sad reality is that what you see most often is people only focusing on pros of every option.

Going back to our Microservices example, people say things like:

We should rewrite our X to microservices; it will lead to better design because:

• “each service will be very small and easy to understand.”
• “it will be easy to write every service in a different language, and we have a hard time finding developers for our current tech stack.”
• “company Y wrote on their blog about doing it, so this is the way it is done these days.”

Let’s forget for a second about the real value of those opinions. Why is that they always use the pros?

I think the simple answer is that they already made the decision and they are excited about implementing it. All they need to do is to convince the rest of the team that this is the way to go. That’s obvious and simple and if you feel strongly about something you should try your best to convince others. Hmm… or should you?

What is our role?

Maybe as developers, our responsibility is something else?

I believe that we are paid to solve problems. Most of the times this means writing code. When it does, the code should be as good as possible, within given constraints. Believe it or not, that does not always mean “the cleanest,“the fastest,“with 100% test coverage,“with most scalable architecture,” etc.

Sometimes the fact that it would be easier to write new functionality after we rewrote the whole thing as microservices does not matter that much compared to the huge cost of weeks or months of a team effort of the rewrite. Not to mention the rough moment when we try to switch.

You probably don’t need as many developers as you think, and you can always find one or two more through referrals. What is more, if you hire new people for writing microservices, and they don’t get the benefit of working closely with the rest of the team, they will have trouble learning the domain and getting good feedback - this could result in having different quality in every microservice.

100 or 200 blog posts on the subject of microservices don’t mean everyone is doing it, and even if everyone would start - it would take years before our technology stack would get deprecated.

It is all about trade-offs.

What should we do?

I think that we should try harder, to be honest when we think about proposing solutions for technology and architecture.

Yes, ReactJS is cool. It’s something new, although that word means something else in the crazy JavaScript ecosystem. Compared to the jQuery code you wrote for your last project it looks more abstract, like if you were writing an application and not only thinking about the things that need to happen when you click on a button.

I know what you are thinking about: “this is so cool, how do I make my team use this at work?”. You want to go and start listing arguments like:

• “when used with Redux it’s so functional, you don’t have to worry about state.”
• “Facebook is using it everywhere.”

Please stop and take a second to think about those things:

• Do you have that much UI that the state management is even a factor? Even if the application gets twice as big as it is now, would it be that hard just to use the simple jQuery stuff?
• If the JavaScript code of your UI is very complicated does it mean it would be right just to rewrite it from scratch? Can you make it better by progressively fixing some of the issues?
• Do you have people experienced enough to clean and maintainable React code?

If you quickly answer yes to all of the above, I have one more request before I let you go to do your thing. Slow down for a moment and try to quantify it. By how much is React better than what we have now? I know this sounds crazy. How can you say “Rewriting our code jQuery to ReactJS will be 30% better”? But please try hard, maybe you can do it.

Finished? You still think that putting a number on it is not possible? Well, maybe this means that at the end, it’s just a matter of taste?