DEV Community: Grygoriy Gonchar

What I believe is a triangle of success for Software Architects and Technical Leads

Grygoriy Gonchar — Tue, 04 Sep 2018 21:11:58 +0000

In recent years I have been working as a Software Architect in multiple organizations including technology companies and high-growth startups. Being both an individual contributor and a manager of an architecture team. I realised that there are three most important principles that help me to do my daily job. I always try to get all the decision contributors on board, try to understand the business and cost impact and take my time coding. There are some more principles I could find important but those three I find astonishing. They are my personal triangle of success (thanks to HBO for the name inspiration).

If you are not convinced why architects or technical leads are needed, you may want to check my other story first — Software Architects and Autonomous Teams.

Make your crew share the mission

It’s easy to get into a trap that it’s enough to convince only management in your decision or just establish a rule as an architect. Nowadays we have autonomous teams living with isolated microservices and teams have to balance conflicting priorities. It’s easy to cut the corners or take the shortest path. If you do not convince people why a certain decision is important, they simply might not find enough time to follow it. Make sure everyone understands the mission and is highly motivated. Afterward become a part of the mission yourself by hands-on contribution.

Involve contributors in making the decision

Before calling any idea a decision, present it to the people who would directly work on it. First, you get a valuable feedback and second you make sure that decision is shared and understood. At @ebaytechberlin we found that Architecture Decision Records presented as a pull request work pretty well. But before making a pull request there are other steps you should take.

Discuss technical idea on the whiteboard first

I find that nicely written down proposals are harder to change. As soon as any human invests a significant effort into something, emotional attachment comes into play. In this case, you can be biased towards the initial proposal. Better to present your ideas as a draft and discuss the ideas of others on the whiteboard first. This allows to have more discussions and adopt the proposal on the fly by moving together in the right direction. The instrument could be not necessary a whiteboard but e.g. a pull request. The idea is that initial proposal should support flexibility of changes.

Make sure you document disadvantages

We all know there is no silver bullet. Almost any technical decision is a tradeoff. Usually, logical people disagree with decisions because they don’t see tradeoffs in the same way. Make sure you explain why certain advantages overweight disadvantages for your current project. It’s a good idea to include tradeoffs, consequences, and disadvantages into Architecture Decision Record and document why they are less important than the advantages of the solution.

Present decisions to all the affected stakeholder

Once the decision is taken the job is not over. It’s only the start of the journey. By making transparent to other stakeholders why the team takes a certain technical direction you increase chances that priorities will be balanced in a right way to make the decision happen. You should also make sure that not only engineers but Product Managers and Engineering Managers understand the technical vision. Make sure your technical goals have meaningful name and values also for non-technical people. “Refactor event collector” is a nerdy name none of your product managers will understand the value in. “Remove unjustified proxy for event tracking to add handling of the new events faster” is a lengthy but already a meaningful name.

Understand the cash flow

Every successful engineering organisation needs to be financially successful in order to continue its mission. This should be one of the primary concerns of technical leads.

How much $$$ different solutions cost

Learn how much certain cloud or hardware services cost and how much an average engineering hour cost to your organisation. How much learning the technology by yourself will compare to the costs of hiring an experienced consultant. Good architecture is also one that achieves business goals at optimal costs long-term. Without putting rough numbers on your decisions it’s hard to make them right.

Participate in product requirements grooming

Product refinements are the only team meeting I try to attend constantly as an architect. As a technical visionary, you need to know extremely well how your future system needs to work. Being present when a product manager presents new features and catching all the nuances of certain product decisions I find extremely useful. But keep in mind, if you are an architect or another kind of a leader who is not part of a team, you should be rather a listener in team meetings. The main purpose of this kind of attendance is learning business requirements. Take active part only when a significant decision has to be made and it doesn’t go in the direction which you believe is optimal.

Spend some time in a customer chair

It might be a good idea to spend a week together with your operations department or together with your customer support team. I don’t say you should stop you work for a week and sit on call to receive your customer calls. But if you are not dealing directly with UX or front-end it’s easy to build false assumptions on how your product is used and operated.

Know the metrics

The other complementing way to know your product is to learn from data metrics. Who are your customers and how many you have. What are the feature people use on your platform the most. How much traffic should a certain feature handle should be a data driven decision. You may take many ideas from Product Management to learn for best practices in this area in general.

Know strategic goals

Know the strategic priorities of your business. Nobody can predict the future and you should not build what is not required. But it helps to know the direction where the ship sails. What are your competitive advantages on the market and what are your key strength that you need to keep. This will let you know where to invest your time more and what is more important for business.

Know your car from inside

The person who was a JavaScrip expert 5 years ago will not automatically be an expert today. “I have decades of experience” is not an argument in the technology field today. Things do change and you need to stay up to date. Also, the person who demonstrates the product and codebase knowledge in practice earns more trust when it comes to proposing decisions.

Keep the balance with coding

There is no ideal time how much you should spend hands-on. It highly depends on how long you are on the project, how deep you know the product and how deep you know the technology stack. The main idea is that coding is no longer a main duty of the technical lead. If you code too much you will not have time to do your most important job.

As a technical lead you can create a much higher impact to the organisation by enabling the right technical decisions and not by the code you deliver yourself
At the same time, you need to know your codebase and product deeply and by yourself. You need to code as much as needed to keep the balance between those conflicting priorities.

Find time to code

Being a technical leader you will find out that you spend too much time on meetings, working time gets fragmented, you no longer can concentrate enough and code contribution becomes a challenge.

Tip #1 Structure your work. As a rule of thumb, I don’t even try to code when I have a time window less than an hour. Even though I try to dedicate a meeting-free day to hands-on work completely while during the days with fewer meetings I review pull requests, create documents or talk to people.

Tip #2 Make a bigger contribution during “low” architecture seasons. Each project has much more design decisions at the beginning. You will be highly involved in those and will have less hands-on opportunities. Just accept this and as long as the project evolves you will get more time for bigger and significant contributions.

Select your coding tasks thoughtfully

If you are not attached to a single engineering team it might be not obvious how exactly to contribute to production code.

Tip #1 As an idea what contribute to, take the first step in the most challenging or least pleasant job. You should not take only candies. You need to make your hands dirty and lead by example. If you was pushing hard for the painful refactoring — you should be the one doing it as well.

Tip #2 You should contribute to the production code and not only work on prototypes. Just coming to the team and saying “Hi, can I code a sprint with you” will work but is not an optimal idea. For the team it might look that big brother is watching them. Instead, it’s better to find a team that actually needs a help. This could be a team with multiple members taking a vacation or just a fresh team which doesn’t know the lay of the land yet.

Stay deep

Congratulations, now you are the technical lead. You won’t be coding the whole days any longer because you have different duties. You should stay deep at least in a few disciplines. It’s being almost a 5 years since I’m not a Software Engineer by title and don’t spend my whole day coding. But I still can hint a solution to some tricky Java errors to even my most experienced colleagues. It is important not to become “Jack of all trades” who has only broad knowledge. I could hardly imaging being a good architect who proposes optimal solutions without staying deeply technical.

There are many ways how to create impact as a technical lead or architect. Don’t be afraid to take some time on learning your product, codebase and explaining your technical vision. The most important work you need to do is to have the right decisions in place and make them materializing. Effectively 99% of your work is just to prepare the technical vision by learning and contributing.

Originally published at medium.com/@ggonchar

Selecting an Application Database

Grygoriy Gonchar — Fri, 07 Jul 2017 14:35:17 +0000

Selecting data storage technology I would name one of the most important technical decision that has to be made. Wrongly selected data storage can prevent you from being able to meet software requirements. Database choice requires thoughtful design and research investment and should be done with maximum responsibility. Here I want to share my knowledge and thoughts about how to choose right database for your task.

Understand difficulty of the problem

While some applications need to store petabytes and process them in sub-milliseconds other applications might need simple storage for the data that fits in memory of your laptop and can wait seconds to be available. Not all applications are equally tough and technology choice is not equally important. Mission critical systems require thoughtful design: feature comparison, prototype implementation, performance testing but not every system needs these steps. For simple tasks you might use already adopted technologies. Invest time appropriate to the value of the problem.

Gather requirements

Everything in software engineering starts from that. Try to understand your data model and ways your application will interact with it. Try to estimate the size of your data. Get throughput and latency requirements. Understand which consistency guarantees required and if linearizability required.

Consider SQL by default

Today SQL vs NoSQL is not about SQL. Traditional SQL databases like PostgreSQL or MySQL already support unstructured document store in JSON or other formats while NoSQL databases evolved query syntax to reach capabilities close to SQL. The main difference remains in the fact that SQL databases are built by default for non-sharded setup with single write instance and few read replicas. This is the way how full ACID can be met without heavy 2PC-like protocols. Consider anything else then “30-years old legacy” SQL database only if SQL cannot meet requirements in terms of the size of data, throughput, latency or query capabilities. With SQL you are sure you can query almost everything and make data durable and consistent at any time. You are on the safe side if requirements will change or if you realize that you made wrong assumptions on your data model.

Anything better comes with the price

To do anything better then SQL database we have to sacrifice something. Usually, this includes consistency, durability, and ways how you can access and manipulate your data. Need to write more data faster? Don’t write immediately to disk or don’t update indexes immediately. Writes cannot be handled by single instance? Remove consistency between documents and spread them across the cluster. Want to have faster access by key? Change how data is stored and remove some query capabilities. These are rules of the game caused by real world hardware limitations. Every characteristic of NoSQL database that outperforms SQL comes with sacrificing some SQL database capabilities. There is no free lunch here.

Right question contains the answer

Assuming the problem is big enough or specific enough. By classifying the problem we find and answer already. Need to store key/value data? Look on key/value stores. Write intensive workload? Look at write optimized solutions. Want to store relationships? Look on graph databases. But only if your problem is big enough or specific enough.

CAP classification is not that helpful

While CAP theorem is absolutely valid classifying databases into CP, AP, CA is usually not. Most of NoSQL databases can be tuned to the level of consistency that is required. Focus rather on understanding database architecture and which problems and use-cases it typically solves. Find experiences of others.

Don’t trust marketing to full extend

Every database according to white-papers is best, fastest and the most reliable in the world. No one will write limitations on the main page or in whitepapers. They are usually hidden in documentation or even hidden that much that revealing them becomes surprised to many people. Jepsens by Kyle Kingsbury is a good example of exploring database limitations in hands-on tests. Measure don’t trust. Benchmarks are tricky business. You can find a benchmark where database X outperforms database Y and another one with database Y outperforming X. Only your setup and data can give the confident answer.

Understand limitations of free editions

I cannot name any single popular database behind which there is no company making money. Even those technologies born and open sourced at companies like Facebook and Google have already consultancies and companies offering commercial editions. More tricky are the databases born because of NoSQL trend. They are developed by companies making money on these technologies and this is fair. That’s why free edition might be very constrained forcing you to pay for commercial one. Understand limitations of selected edition. Frequently they include security, replication, monitoring, bug fixes and are vital to many systems. Do this early in your project and align with your budget.

Understand limitations of hosted options

There are many databases provided as a service such as Heroku Add-ons. You don’t have to deal with infrastructure, replication setup, and backups. Everything is there to start implementing an application. Usually hosted databases are more expensive than just bare metal machines where you can setup any database with a license. But the price difference is not the only cost. Database maintenance as a service prevents you from being able to use some administrative capabilities directly. This means you might not be able to create multiple users with different permissions, install extensions or even change durability/consistency level. What you will get for sure is database communication protocol compliance but not all the features. Evaluate these limitations carefully.

Is it right time to play

Experience matters. Knowledge inside the team matters. Old and known is better than new and unknown. Heterogeneity brings complexity. Distributed systems are tough. Building databases is tough. Everything old and tested is better than new and fancy. Trying new technologies is always a risk. Trying multiple new technologies at the same time is a big risk. Not every task and circumstances allow taking this risk. Understand if you can allow yourself trying new technology which should be better then already used and adopted one. But not every problem is a nail you can fix with a hammer. There is no “best” database. There might be the most suitable one for your problem.