Today’s IT world works at two speeds. Two irreconcilable basic philosophies face each other without understanding each other.
One, driven by startups and tech giants (Google, Amazon, Netflix and many others) who push the limits of technological concepts every day, and the other, sitting on its certainties and only evolving when it can’t do otherwise, which is mired in its processes and only sees things in the long term.
The industrial approach
The approach, which we’ll call “industrial” therefore has a long-term vision of things. Environments are made to last and must be thought out in times proportional to the longevity of infrastructures that will be born from them. We lose hours in meetings to define each point that will then be detailed in documents that will only be read once by teams to whom we’ll redistribute development tasks (often via contractors) without giving them a global vision of what we’re trying to achieve.
We often end up with a dilution of responsibilities and mechanical work from actors supposed to bring value to these dantesque projects. The disempowerment is all the greater as these teams also don’t have to maintain what they’ve produced, since operations teams will take care of all that afterwards. With short deadlines and tight budgets, we do what we can, and too bad if it barely works and generates errors.
Code qualification and acceptance periods are supposed to erase problems. The effort provided for putting together code from different teams is important and often painful. But these environments can ultimately never be equivalent to those intended for clients, and we’re never sure of the result during production deployment. However, these environments are hell to maintain and require an effort often greater than production itself to be kept operational for developers.
Freedom offered to developers is most of the time null or very limited, specifications being written often well in advance. They are therefore considered as executors. It’s thus difficult for them to live a “passion” profession. The same goes for operations teams who must maintain “blindly” systems on which they decide nothing. Time is lost at all levels and the final result is never the expected one.
Much frustration is felt at all levels, both at the level of project managers, developers or admins and system technicians. Often, rather than questioning the system, we end up blaming each other from one team to another and the general atmosphere can more surely turn into trench warfare than pooling skills to find the source of problems. All this is wearing and demotivating.
The startup approach
Born from all these frustrations related to this vision of projects, new approaches have emerged, like devops or agility. These philosophies have a common goal: put humans back at the center of concerns and replace communication at the center of work principles. Team empowerment also becomes a major issue in IT projects.
The micro-service approach brings a subdivision of projects that allows reducing perimeters and therefore making them easier to understand and maintain. According to the KISS principle (keep it simple, stupid), the smaller things are, atomic, the easier creation, maintenance and evolution is. A micro-service becomes a project in its own right. The team in charge is thus reduced and communication is therefore better. When a micro-service has no planned evolution, it’s not (or almost not) useful to test it. Our micro-services also don’t need to be written in the same language.
Agility allows treating the project manager role in a collegial way by providing many tools to manage as a team tasks to do and the scheduling of developments within the team. We also know what everyone does and speech is free to discuss choices and orientations taken by other team members. This empowers the team which makes choices together on project progression.
DevOps allows bringing development and operations professions around the same table throughout the project’s life. DevSecOps even extends things to security teams. It’s ultimately about assuming as a team all aspects that will allow producing better and more efficiently. We could extend this to UX teams, or any other profession on which the realization of applications that best satisfy those for whom/which they are made depends.
The Lean startup approach teaches us fail fast. We must no longer be afraid of failure. We must bring an idea into production as quickly as possible to validate that it’s good. We’re not going to spend months framing and polishing an idea and deliver a final version that could be a crushing failure. We’re going to produce quickly, in a non-definitive way the new features, and we’ll continue their development only if they’ve had a favorable reception or good results to answer the problem for which they were created. We deliver more often, we measure results just as often and we decide on actions to take on the next development cycle.
These are the basic principles. This list is not exhaustive, and concepts are not to be taken as rules to follow. The team must know how to adapt and adapt methods to its needs. What prevails is understanding what they’re for and what they can bring. We adhere to them or not.
The startup approach is a mix of these different methods applied to what we want to do. We learn to make “disposable” code and infrastructures. We no longer seek to create perfect projects. We subdivide perimeters and teams to favor communication and simplicity. We learn to compose with failure instead of dreading it. We learn that communication is more important than chosen technologies.
What each thinks of the other
The industrial world sees the startup world as:
That of “fads” where nothing lasts, where security doesn’t exist and processes are non-existent. How to make reliable applications and produce stable infrastructures when working in a bohemian environment? We invent job names that don’t rhyme with anything and that change all the time. We ignore proven methods that we’ve been using for decades and that we know are reliable, to go towards the unknown and use in production tools that aren’t even in final version, as was the case for docker, kafka or even terraform. Startuppers come to give lessons while they don’t respect simple rules that govern production as we know it. We fix maintenance problems by removing maintenance and destroying everything to rebuild it. ITIL shatters and we lose the love of the profession that allowed us to produce systems with care that we were proud to show for their perfection. We also lose a lot of time and energy in things that aren’t work-related like “paintball outings”, interior decoration in offices that sometimes looks like kindergarten decoration and the famous “Chief happiness Officer” supposed to manage this band of spoiled kids.
The startup world sees the industrial world as:
That of slowness and sadness. That where you enter young and passionate and from which you exit worn and drained of all hope. How to make reliable applications and stable environments when we still reproduce the same errors for decades? How to improve when we don’t know how to evolve? In a world that evolves even faster than it has ever evolved, why plan long-term? Why spend months planning projects that will be obsolete as soon as they come out? Why still produce large-scale projects without dividing them and again and again suffer delays and end with inconsistencies with the initial project? Why lose so much time and money maintaining multiple environments, obsolete tools and languages and mobilizing teams that don’t talk to each other and work each in their corner? Why be content to use old technologies when a whole bunch of new tools appear and allow us to be much more efficient and make infrastructures scalable? And finally, why work in sad and gloomy offices when we can have fun at work? Because there’s not just work in life, and we’re much more productive when we have fun and are happy.
To conclude
You’ll have understood, having lived both philosophies, I have trouble finding excuses for those who refuse to evolve. However, I can understand this fear of chaos and instability that comes from having to constantly question oneself and trust tools that change all the time. Some industrial frameworks impose long-term rules, like for example machine tools that will have to remain operational offline for 20 years. But not all are as restricted as this one. An industrial company’s website doesn’t need processes as strict and lasting as an airbus A320 autopilot. You must know how to be strict and conservative when necessary, but know how to let go when you can. Conversely, having the possibility to work with new tools is not an injunction to do it. If we change everything, all the time, it’s difficult to find in the long term stability and sustainability.
The truth is therefore between the two and depends on constraints that apply to the project. But principles aiming to reduce large projects into multiple small independent projects seems to be a good improvement axis. Considering multiple teams as so many startups that have their objectives, their micro-services and their clients will facilitate the global vision of the project as a whole.