Hype driven development

Software development teams often make decisions about the software architecture or technology stack, based on erroneous opinions from social networks and everything that is more fashionable than well-studied, without a serious assessment of the possible impact on their projects. I call this trend “Hype Driven Development (HDD)”, I consider it harmful and advocate a more professional approach. Let's see how things are going and what we can counter.

New technologies - new hopes

Have you met with like? The team chooses the newest, hottest technologies for use in the project. Some of them are reading a blog post, a trend on Twitter, or have just come from a conference where great things have been said. And now the team uses this brilliant technology (or a new paradigm of software architecture), but instead of the promised high speed of work and high quality of the product, they get in trouble. The pace of work slows down, motivation disappears, difficulties arise with the release of the working version. Some teams get stuck at the bug fix stage instead of adding new features. They need "a couple more days to clean up everything."

Publication support is Edison , which is developing an SDK for tracking geographic objects and a system of online accounting for the Furniture for Home store chain .
')

Hype driven development

Sources of such hyip may be different:

• Reddit driven development - a statement by a famous blogger or published material on sites such as reddit, hackernews, blogs twitter, Facebook, GitHub, etc .;
• Conference driven development is an inspiration after attending the conference, which is actually a double-edged sword: using the latest, latest libraries / interfaces / technologies without experience handling them can be expensive to hell;
• Loudest guy driven decisions - loud chatter of a guy who just can not talk about the novelty, which, eventually, will convince the team of the need to use it;
• Gem / lib / plugin driven development - a new gem appears within the Ruby On Rails community that you download to fix the problem, although writing a couple of lines of code yourself would just as easily solve the problem. But no, we'd rather add the library, the plugin, the gem, etc. ...;
• Stack Overflow driven development - it is also worth mentioning the abuse of thoughtless copying of solutions by programmers from the Stackoverflow resource (or even from the Internet).

HDD - a sentence that programmers make themselves

The problem is that bad decisions are made in the heat of passion. And the consequences can haunt the development team for months and even years. In the worst case, they will lead to a total edition. Which almost never succeeds.

The root of evil is the media in which the idea spreads faster than it is tested, faster than people manage to understand its advantages and disadvantages.

Anatomy of HYIP

Most HYIPs have a similar structure:

Step 1: The Real Problem and Solution

In some companies face the problem. The team responsible for the decision determines that the problem cannot be resolved within the framework of the current architecture or technological processes. The company creates a new framework, library or paradigm and soon the problem is over.

Step 2: Announcement, Vanity and Keywords

The team is excited to see a chance to show their work to the whole world, and now they are writing on blogs and speaking at conferences. Often the solved problem was non-trivial, so they feel pride in describing the non-trivial solution they found. The audience learns about new technology with admiration. However, the admiration of the audience does not imply that all its members fully understand what the problem was or do not go into the details of the solution.

After all, it was still a non-standard task with a non-standard solution. And for clarification, you need a little more than tweet, a couple of lines in the chat, or even a blog post. In modern media, the message may easily become fuzzy and blurred as it spreads.

Step 3: Madness begins

Shortly after the news went through blogs and conferences, developers around the world are starting to get acquainted with the new technology. And some of them, due to the vagueness of the information, make a hasty decision to use the described technology, even if it is not able to solve any of their current problems. But they believe in it.

Step 4: Disappointment

Despite the desperate efforts, technology does not make life easier for people, but, on the contrary, delivers a lot of additional worries - a huge amount of rewritten code and time spent on learning. The work team is slowing down, the management is extremely dissatisfied. People feel cheated.

Step 5: Implement!

Finally, the development team, reflecting on the past, is aware of the purpose of the technology and in what cases it will be most suitable. They become wiser ... until the next such hype.

Examples of HYIP:

Example 1: React.js

• Step 1 : Facebook has a problem - the application hangs with a large amount of information.
• Step 2 : Facebook announces a new paradigm using buzzwords: functional, virtual DOM, components.
• Step 3 : Mania. Facebook has created the external interface of the future! Let's quickly write comments!
• Step 4 : Wait, there is a lot of work, and quick return on investment is not expected!
• Step 5 : A solution was found for advanced single-page applications with a large number of real-time notifications, and would not necessarily be suitable for simpler applications.

Example 2: TDD is dead due to DHH

• Step 1 : David Heinemeier Hansson (DHH), the creator of the Ruby on Rails framework, announces that it is difficult to combine development through testing (Test-Driven Development, TDD) with Rails, because the latter does not have an architecture to support proper object-oriented programming. And makes a pragmatic choice - do not write tests in advance.
• Step 2 : Hysteria begins with Henson’s post on the blog and speaking at a conference. Tags: TDD is dead.
• Step 3 : Let's skip the tests! Our guru said so. We still did not write them. Now we will not pretend. Finally, down with hypocrisy.
• Step 4 : Wait! Now there are even fewer things than before. We made a clumsy code.
• Step 5 : “TDD is not dead or alive. TDD is a concession that includes the risk of changing the software interface of the application, the skills of the contractor and the existing design ”- Kent Beck.

Example 3: Micro Services

• Step 1 : Difficult to assess the scalability of a large monolithic application. At a certain stage we can break it into several services. So it will be easier to determine their ratio requests \ sec.
• Step 2 : HYIP Keywords: scalability, weak connectivity, monolith.
• Step 3 : Let's rewrite everything and break it down into services! We have "spaghetti code", because we have a monolithic architecture! We need to paint everything on micro-services!
• Step 4 : Damn! Now the application is developing so slowly, it is so difficult to install and so much time is spent searching for errors among various systems!
• Step 5 : Micro services require high skills, both in development and in the field of information technology services, and with the right investment can eventually become more scalable. But before you reach a certain limit, it will be excessive investment. Micro services are retrieved, not written. You must be tall enough to use micro services.

Example 4: NoSQL

• Step 1 : The SQL database has problems with a large number of loads and unstructured data. Teams around the world are starting to develop new generations of databases.
• Step 2 : HYIP Keywords: Scalability, BigData, High Performance.
• Step 3 : Our database is too slow and not large enough! We need NoSQL!
• Step 4 : Do we need to join tables? Will not work. Simple SQL operations become complex. Development is slow and our key problems are not resolved.
• Step 5 : NoSQL tools are designed to solve specific problems (huge amounts of data, non-structured data, a large number of downloads). SQL is actually a great tool and it can handle a large number of downloads and a large amount of data if it is skillfully used. There are not many suitable situations for NoSQL for 2016.

Example 5: Elixir and Phoenix (or any other favorite language / interface pair)

• Step 1 : Network frameworks such as Ruby on Rail are not really designed for high performance applications, distributed applications, or web sockets.
• Step 2 : HYIP Keywords: scalability, high performance, distributed, fault tolerant.
• Step 3 : Oh my god, our application is slow and our chat is not scalable!
• Step 4 : Wow, learning functional programming or a distributed approach is not so easy. We are moving very slowly now.
• Step 5 : Elixir and Phoenix have proven themselves well, but it takes a lot of effort to get comfortable with them. It pays off in the long run if you require an application with outstanding performance.

The list of examples is endless

In our densely populated circle of computer developers there are a lot of areas where HYIP is a common thing. In the JavaScript world, new frameworks appear every day: Node.js (keywords: event-oriented programming), reactive programming, Meteor.js (keywords: shared states), front-end MVC, React.js. Give yourself an example. In the field of software development, new architectures appear: project-driven development (Domain Driven Development), Hexagon, DCI. What hype do you like most?

Fair practice

If we cannot rely on the Internet and the opinions of other people, then how can we make smart decisions? Here are some practical tips.

Test and research before making a decision.

• Explore your technology yourself, and do not read about it in blogs. Take a day or two to prototype a new technology before making the final choice. Let the team analyze all the pros and cons. Or use only a couple of competitive technologies, and let the rest be tested by your programmers.
• Spend hackathon is a great way to set your team to caution when introducing new technologies. Let them work with new technologies for today and select the most promising ones for one or two days. Their decisions will be more balanced, because will be based on their own experiences.

When?

• In principle, when the return on investment is significant. Most technologies are designed to solve specific problems. Do you have this problem? Does this decision save you time? Will the use of technology pay for its implementation and the associated difficulties? What if work eventually becomes twice as slow? Or four? Is it still worth it?
• Great programming teams are more allowed - some teams are simply beginning to benefit more quickly than others. They get bored working with what is easy. These teams may be more likely to introduce new technologies. This is no excuse for not using hackathons and seriously not analyzing new offers. On the other hand, if the team has problems with the work, be careful with new technologies.

Hire the right people:

• Serious technical training is your friend. People who are familiar with different paradigms, understand programming theory (for example, algorithms, parallel computing) and have a good engineering culture, are less prone to HYIP.
• Experience - hype loves young people. Over the years, people who have seen many different new solutions and have encountered many times difficulties, choose technology more soberly.

Translation: Sergey Danshin