Code-Driven

In order to improve the software development process, it is crucial to deeply understand each and every part of it. The most important part in every software development process is of course the software engineers who turn ideas into code, and code into profitable product. This article dives deeply into what kinds of engineers are out there in the industry and how to take advantage of their diversified talents to ensure a successful software company!

In the industry there are two kinds of engineers:

Code-Driven Engineers

Code-driven engineers were usually those at the top of their class when they graduated. They tend to be the type who focus on the ones and zeros of every popular compiler out there, and heck, they might have even built their own at some point!

These engineers are usually not very sociable like introverts, but they get delighted and very much enjoy a conversation about the newest design patterns, and what would be the asymptotic time of a recursive function verses a function that implements iteration.

These code-driven engineers are the assurance of your software safety when things fall-apart, because they are fast-thinkers in the code-verse and they will be able to pin-point a production issue and fix it before your end-users even blink.

But more importantly they are the ones that assures your software readability, maintainability and resilience against high volumes of requests/data - but they shouldn't be your visionary vanguards when exploring the market.

Product-Driven Engineers

Product-driven engineers, on the other hand, are not usually the grade A type of engineers, but they are always up to date on which software is making a huge splash out there in the market. They are always reading about and quoting successful leaders in the industry, and they are definitely always looking forward to becoming one themselves.

Product-driven engineers enjoy explaining how code works to non-engineers, therefore have very high social intelligence. In an Agile environment, they are the negotiators with managers and stakeholders, always taking things even further because they are more candid and straight-forward so they end up becoming tech-leads more readily than code-driven engineer’s due to their ability to effectively communicate with non-technical management types.

Companies need product-driven engineers to keep your product up-to-date with the latest patterns. They are more knowledgeable about what sells out there, they are also very aware of old routes other software companies have taken, and why these paths may have failed or succeeded and how to either avoid or emulate those steps.

Those engineers will help you find the path, but they shouldn't be the one building the final product.

The Concept

The software industry definitely does best when both types of engineers are paired together. Companies need product-driven engineers to pave the way and find the missing link for the right product that people will actually be interested in, and this requires serious experimentation. So the faster we can market the product without getting tangled up in overly ambitious code-control, the better off the software company is as a whole. The focus is kept on the product itself which is, of course, the meat on the bones of the profitability.

On the contrary, a high level of discipline is required to blow-up your entire working, profiting software and when you start rebuilding it from scratch will make it maintainable. This is where code-driven engineers come in to fill that need.

The longer I work in the software industry I realize that we can’t turn one engineer-type into the other. This is something that is hard-wired into the personality or into the nature of code-driven engineers to refactor and abstract and test-drive every single aspect of their code. The same goes with product-driven engineers - they don’t seem to have the patience to sit two hours through making a code that’s already working, work again!

This is where pair-programming comes in to play here with an amazing result. In a pair-programming session you need someone to code and someone else to drive the development and keep the coder on track Both are very important in the process of creating good software, but there’s a little bit of a role switch there depending on which stage of product development the software is in.

It All Depends on the Stage

When the software development is in the prototyping stage, you want the product-driven engineers to be the ones writing the code, and the code-driven ones to be watching, because the product-driven engineers will write the fastest, easiest thing to get something out there to the market, even though it would be hard to watch for a code-driven engineers. It is actually quite important that they actively watch to ensure the code written even if it is at this stage is very unmaintainable, that it doesn’t cause a catastrophic irreparable issues such as clients losing their data, credit cards information, server failure and out-of-service nightmare.

But when the software is in the refactoring stage, now that we know people actually will use this software, you want the code-driven developers to be the ones writing the code. Whilst the product-driven engineers making sure their pairs don’t go off track or waste too much time on an edge case that is 1 in a billion to happen, (in short making sure they keep the development from turning into a science project), unless they are actually working at a lab somewhere at Area 51 then this article is totally irrelevant!

In the refactoring stage product-driven engineers also make sure their pairs are not changing the product from the way it is out there “because it makes more sense this way”.

Balance-First

Both are very important to achieve balance, a software development process becomes very slow when two code-driven engineers are pairing on something. They’ll consume all the estimated time and there will still be no actual marketable product out there. The same goes to two product-driven engineers pairing on a feature – the code will be very hard to maintain, let go of the fact that it might cause irreparable damage to user's data, and some important edge cases will be missing because “that doesn’t matter right now” or “I don’t think people will use it this way” - but guess what? They will!

If the development was totally up to product-driven engineers the result would be a very poorly designed software that’s almost unmaintainable, maybe not optimized to serve huge amount of data. But on the opposite side of things, if the development was solely up to code-driven engineers, they would turn everything into a science project, and nothing will ever get out of the door, because “I can make this better” syndrome.

Not Black or White

This balance is very important, and it may vary between one engineer to the other It’s not always 100% code-driven, neither is it 100% product-driven, even the most product-driven engineers I have seen still had some “nerdiness” in them, same goes to some of the code-driven engineers I worked with. They still get excited to see how the market reacts to their work and become even more interested into improving things the customer didn’t even ask for. When I say code-driven. I mean engineers who have more tendency to assure maintainability and beauty in their code even if the product isn’t really worth that effort. These product-driven engineers are the ones who keep thinking of the end-result whilst they are still deep in the weeds of initiating their solution.

The Team

It’s important for a self-aware software team to know their strength through these very categories of engineers. It allows the team to be able to manage their resources better and focus on what matters the most whether they are at the prototyping stage, or the refactoring and maintenance stage.

Glimpse at the Past

If you look at the history of developing software you will notice that these two types of engineers always existed in most of the popular software out there. Look at Steve Jobs (product-driven engineer) and Steve Wozniak (code-driven engineer) – Apple wouldn’t have been possible without both of them, as a visionary engineer needed to be out there to know what people really would need, whilst the computer scientist would back that vision and make it possible.

Real-World Examples

If you look at the software market today you will see these two types on a larger scale; Twitter is the de facto for coding standard for Scala, and the ultimate reference for Bootstrap styles, however Twitter isn’t making any money. Entrepreneurs are still wondering how to make that product profitable.

On the contrary, Facebook is not a de facto on anything. Some of the interns at Facebook reported in many blogs that it’s all just code-and-push, no revision, no testing, and very poorly standardized development process. But Facebook is making a lot of money.

A successful software needs to be maintainable, but also profitable, but the profitability has to come first before maintainability to be able to bear the costs of refactoring and engineering. Twitter started with maintainability so they suffered large losses in market-value. Facebook started with profitability, but their code is very hard to maintain.

Facebook today has more chance to get back on the right-track (and they are) because they have the funds to rewrite their entire platform without their users even noticing that it was all rewritten from scratch. It becomes harder for companies like Twitter to get to that stage as it burns funds every second of everyday without any gains.

Prototype First then Nerd it Out!

Learning from Facebook vs Twitter example, a good conclusion would be to encourage prototyping before spending months and months in developing software that doesn't really sell, and when prototyping make sure you employ your product-driven engineers to take the lead and explore the market until they find the right product for the right market.

Knowing whether a given product has a potential or not is not done by market analysis or speculations, it's by actually hitting the ground of reality and seeing how people react to it.

No one could tell you how your product is doing like your end-user, so make sure to get that honest opinion as fast as you could.

Zuckerberg once said: "Entrepreneurial culture thrives when it is easy to try lots of new ideas, Facebook wasn't the first thing I built"

The Future ...

In the end, I think a deep understanding of a team and its abilities plays a big role in determining the success or failure of the software itself, in light of the categories mentioned above, that might be a good start in understanding how we can optimize our development process with a good strategy to meet business needs at the lowest costs without suffering from poor quality.