A passion for programming. Chapter 18. Automate Your Work

About transfer

This is the translation of Chapter 18 of The Passionate Programmer: Creating a Remarkable Career in Software Development. Its author, Chad Fowler, is a talented Ruby developer, a renowned speaker at conferences dedicated to Ruby and IT in general. Former saxophonist, and now - CTO 6Wunderkinder.
')

Crowdsourcing translation of the book is conducted on github , join.

Chapter 18. Automate Your Work

Throughout my career, there is a conflict between, on the one hand, the desire of managers to get the cheapest (often offshore) companies to work on a project, and, on the other hand, my firm conviction that low developer costs do not always lead to budget savings. I even went as far as technical directors and vice-presidents, furiously advancing on hiring some really cool gurus instead of a legion of low-paid coders.

Is it worth mentioning that I rarely managed to at least finish by the end? The problem with my position is not that I am mistaken (of course!), But that there is no easy way to prove that I am right. And from a budget point of view, the only data we have at our disposal leads to the conclusion that a lower hourly rate is beneficial for the company.

Imagine a spherical project in a vacuum. How many developers will it take to write such software in three months? Five, you say? Six? Well, what about two months? How would you shorten the term?

The standard manager response is to add more programmers. (As if nine women can have a baby in a month!) This is wrong, but this is what they believe. And if, suddenly, you manage to complete a separate project faster, after increasing the number of developers, the management will be 100% sure that the more people, the higher the productivity.

But any problem can always be solved in several ways. If the goal is to improve the development as a whole, you can:

• Find people who can do the job faster
• add more people or
• automate work

Given that we do not know how to actually measure the productivity of development, it is difficult to prove that one person is faster than another. So those who count money can only operate on hourly rates.

This leads us to a simple (and slightly naive) formula that assumes that in a fixed time interval:

As a matter of fact, sometimes it is still possible to calculate the real result from investments in development. But in most cases, ear-tipped factors are used, such as the number of projects or requirements, without any reliable way of counting them.

So, the option with “faster” programmers is too hard to prove, and we do not want to condone the use of cheap labor. We can only automate.

I remember the panic around cuts in the US in the eighties. Then we blamed not only and not so much other countries as technologies and, especially, computers. Huge robotic arms were installed in factories. They were so ahead of the people in speed and accuracy of work that it didn’t even make sense to compare. All were suppressed, except, of course, the manufacturers of these robots.

Imagine that you own a small business website company. The principles of their construction are similar, like two drops of water: contacts, polls, a basket, a section for vacancies, etc. You can hire some really fast programmers who will write websites, build an army of cheap coders who do everything for a long time, or create a system for generating code.

If we substitute some (fairly arbitrary) numbers into the formula above, we get the equations shown in Fig. one.

Automation is the basis of our industry. But, for some reason, until now we are not trying to automate our tasks as software developers. How to produce provably better software faster and cheaper than your offshore competitors? Build robots. Automate your work.


Fig. one

Act!

1. Take any recurring task and write a code generator for it. Start simple. Do not think about reuse. Just make sure the generator saves you time. Consider how you can increase the level of abstraction of what you generate.
2. Explore Model-driven architecture (MDA). Try any available tools. Look for how you can apply the ideas of MDA in your work, if not the whole approach. Consider using MDA concepts using only familiar tools.

---