21 Sep 2014

When will programmers grow up?

Do you still think that high-quality programming skills, knowing SOLID principles, writing maintainable tests is enough for you to be called a professional? Let’s elaborate this topic. Don’t start yelling until you make it to the end.

I used to be passionate about high-quality programming, all my attention was drawn by maintainable, flexible and easily readable code. I was reading hell a lot of literature on this - both books and articles. Later on I started to teach others. I was conducting webinars & tech sessions (both at work and on the Internet), writing articles and discussing these topics at JTalks. And I still continue on this, though way less actively.

Good programming skills can kill projects!

That passion was gradually leaving me. First of all because I had another passion now - Continuous Delivery, and second - it started to seem that people who are well-educated in programming can harm projects dramatically. Here is the best example in my career that illustrates what I’m talking about:

At some point of my life I decided to join a startup. It seemed to be a good option to me: they used modern technologies and frameworks and during the interview they asked me about best practices which was a promising sign. Moreover teleworking was really handy to me at that time. So here I am resigned from my regular job for the sake of intriguing startup.

From the first days it started to look wrong: they didn’t have daily meet-ups to be in synch with each other (only weekly meetings which was too rare for that kind of project) and they had a dozen of repos in VCS - too many for the first months of the project! That seemed suspicious, and it didn’t turn better..

It appeared that last couple of weeks were spent for designing domain model and database scheme (wat?). And they were not there yet! I started to be involved in all this designing and I found that every team member suggested their vision of the model. And here comes the discussion.. That discussion was overwhelmed with buzz-words like “Best Practices”, “OOD”, “Performance” and in the end they chose the most complex scheme suggested.

By that time I had experience in Scrum and project management which gave me confidence that things must change for the project to survive. I appealed to the customer who (surprise-surprise!) was an ex-developer with questions and suggestions on improving the current situation:

  • Team communicated once in a week, for that project that meant they worked couple of days and then waited several days for the meeting to share their thoughts. That’s extremely ineffective.

  • They started with distributed storage, complex designing and performance in mind while there was nothing to optimise and refactor yet.

The customer was irritated by the fact that there was nothing ready by that time. But he was too involved into technical details. He was possessed with “we should implement it in a right way!”. To me that was too ineffective for such a small-budget project. So call me a rat, but I left that sinking boat after 2 weeks of struggling. I didn’t take money from the customer, I knew he’d need them in the near future. Couple of years have passed, but on their website I still see ‘Coming soon..’.

That situation was a good lesson to me - they were possessed with the quality and that killed the project, it was so clear that it opened my eyes. That was the opposite to what I learnt and taught. It was a beginning of my own rehabilitation. I started to realise how stubborn and selfish I was in the past.

I recall working for a small company where I was asked to write a tiny project to mix some videos, list them and show them to the users who can vote. The project had a budget for 2 months and I could’ve make it! But I was too blind because of good practices and maintainability. I introduced complex technologies, caching; of course I split the project into different layers and added a lot of extra interfaces for flexibility. Should I say I missed deadline? Surely I did. I was asked why it took me that long, but it was hard for managers to understand the importance of that complexity. Now it’s hard even for myself! That project didn’t require maintainability, extensibility, flexibility or any other “bility”, it didn’t! No changes were made to that project since then. In retrospective I understand that all that crap was needed for myself, I was selfish. I needed to ramp up my skills (which is of course important), but I did it at the expense of missed deadline. And now, when I hear developers criticising managers, I’m careful in supporting the conversation. Because who knows, who knows..

Be moderate in code quality

I don’t want to say that well-written code is bad, I don’t! And neither I defend bad-smelling code. But both extremes are equally bad. Both situation lead to money lost. On one hand it’s possible to end up with a mess that’s expensive to maintain and which leads to lots of nasty bugs. On the other hand if we put too much of thought into design, the project may die before it’s even born!

But you may still say: “Hey, I always write high quality code that doesn’t smell and I always spend weeks on careful designing, but my customer doesn’t go broke! He still is happy with the results!”. Well, that might be true. But first of all, customer doesn’t necessarily live on the edge, it’s pretty common for the customer to have big funds and even if your project doesn’t bring any value, he still might be happy, he just doesn’t notice ineffectiveness! And second - in the majority of cases the costs spent on the project development are much smaller than overall spendings on the business. Even if customer heavily relies on the software you work on, there is still plenty of stuff to care about: marketing, 3d party contracts, client-facing offices and personnel, taxes, transport, et cetera, et cetera. So in the end ineffective development might not be that important for the business.

Then who cares? If I work in a large wealthy company, what’s the big deal if I’m ineffective? Here is my perspective on this:

  • There is a moral concern: if you get paid, then you probably should be worth your money. This is not a big deal for many people though, most of us are selfish.

  • You probably want to get higher on the career ladder. It’s more likely to get there if you try to help and make your company better. And vice versa it’s less likely in case you don’t give a toss about the business of your company.

  • Many of us like thinking of ourselves as professionals. And caring about your product success is another way of being professional. Such people are much more precious to the company than typical I-care-only-about-code engineers.

  • Most of the time we don’t have such a freedom - we’re put into frames, the resources (money, time) are not infinite. And then you start to care not only about quality of the code, but also about delivery and quality of the product. If you put too much accent on code quality, you’re missing deadlines. And it’s usually a big drag.

Professionals don’t write code, they solve business tasks

Speaking about professionalism. It’s weird to see how arrogant today’s programmers are. We’re so self-important, so self-important! (c) It’s very common to hear a programmer mentioning how cool he is and how miserable was that employer he just had interview with. To me that’s a STOP sign. If I were to notice such an arrogant behaviour from someone I interview, I wouldn’t hire him no matter how cool he is technically. Because these people are selfish, they don’t care about the product, they care about coding and getting money from this process. Keep in mind that a businessman doesn’t care about source code - he needs a solution. And if you can’t provide it, then you’d rather stop calling yourself a professional.

I used to work in one out-staff company. There was our team (off-shore) and there was our customer team (on-site). That was a very frustrating job - our off-shore team was much more experienced in programming, really strong team. Meanwhile on-site team was pretty weak technically. But this fact didn’t matter for the customer, on-site team is always more important than off-shore. Why?! Customer spends a lot of money on the maintenance because of these guys, why the heck they are in charge of the project? That’s again because albeit our off-shore team was experienced in programming, we were much weaker in the business we worked for. Only on-site team could talk directly to stake-holders, only on-site team knew what should be the result. Yes, they were writing an expensive-to-maintain code, but in the same time they were solving business tasks! While we simply didn’t have enough strings to pull and business knowledge to put into the work.

So last years it became clear that it’s more important to deliver a successful product rather than use modern tools and have 100% code coverage. And after that I started to notice that people who care about quality most and who use buzz-words like Best Practices are the least efficient overall (I’m not talking about short-term progress, I’m talking about overall!). With their approach projects get overly complicated too soon and it ain’t add up to the readability. And now if I hear this “Best Practices” junk in a conversation, this is a good sign that person doesn’t quite understand the subject, that he hides his lack of knowledge under these words. An experienced programmer uses arguments and facts instead of authority of best practices.

The last point on technical skills vs. business skills: our purpose as engineers is to make money for the employer. This can be done either by reducing costs or by creating new business value. And thus:

  • With poor technical skills and good business knowledge you’re creating a software that makes money

  • With good technical skills and poor business knowledge you’re creating a software that reduces costs, but doesn’t provide as much business value.

And therefore by caring about business you’re adding new value and by being a good programmer you reduce cost. Combine these traits, know when to write good and when to write fast. And be twice as effective!


How do I learn new technical stuff if I care about business? Of course in order to be a good programmer, you have to learn new stuff and be up-to-date with technologies. A good rule on this - one new technology in the project is enough. It’s much better to be home with your family than meeting New Year at work fixing bugs because of newly introduced tools.

What if project has budget for years, should I apply all my designing skills to make it maintainable? Just be agile! You can’t design everything upfront. Most of your early decisions will be re-written in the future. Write poor code, get business feedback and then re-write it. Check out Fowler’s best seller: Refactoring: Improving the Design of Existing Code.

Interestingly, business ideas also evolve gradually, they also get refactored! But in order to be purified they need to be checked on real market - that’s where rapid and frequent releases will be very handy and money-raising. And in case you’d want to spend too much time on implementing them.. well, you risk to lose money if your competitor implements it first! And that may outweigh maintainability costs.

Should we all stop hating our managers? I didn’t say that! :) Of course managers should be as realistic as others. But professionals are rare in every field, on any position. So it might be typical for your manager to promise too much to his own higher-ups and unleash the dogs on poor developers. Well, shit happens, I’m not advocating such people. Of course this not a professional behaviour, but maybe.. Maybe the problem lies somewhere below, in the realm of programming. Maybe it’s you who’re playing with the future of your project like a kid sitting at the playground playing with his toys. Grow up, be reasonable in your judgements.


Read more