How to start developing internal software and not give birth to a mammoth
We are faced with the development of software for internal use constantly. Web studios make their own PHP frameworks (well, almost everyone has thought again), large corporations order custom CRM and ERP. Everywhere, at every step, every few seconds one programmer or manager on our planet rolls away from the computer after 5 minutes of googling ready-made solutions and says "it's time to cut one's own, this is all not suitable for us."
I will try to tell that most people forget at this moment. It does not matter what they are going to develop - a library for cropping images, a framework, the most complicated plug-in for CAD or another cozy ERP-CRM. Think stop. Googled again, please. Perhaps you should not even begin.
')
An example that is familiar to most programmers:
A few years ago I came to work as a programmer in a small company. I got a computer assembled and a tech scan called me. Called to introduce him. It was a framework written in PHP 3-4 versions. Everything was fine there - and the storage of the executable code in the database, and the admin on the self-made bootstrap from the tables, and the database with the names "__123123". By the way, YII 1 at that moment was already gaining momentum, and Django began to get older. We did not care, we were busy with plans to port our internal development to the OOP PHP. Well, someday. When will the extra resource. That is, never. In the meantime, customers are waiting, you need to start on this framework 5 more projects. We have already signed TK.
I think every programmer has come across this phenomenon in his career. We recall with irony our naivety and blame everything on inexperience. However, this is not the reason. We are doing the same now. Constantly. We give birth to mammoths, who obviously, on the basis of their development plan, must die. And their bones will lie right in our office. Somewhere in the aisle for people to stumble. But these are our corporate bones. We, in principle, ourselves brought them here and thought at this moment with our head.
Let's return to our enlightened employee. He rolled away from the computer in a chair and decided to write software. I don’t know, probably, this kind of software for generating reports on templates. Or not. Probably, this is something that will allow to tear apart the TK on the issue in the task tracker with one click of the mouse. The authorities will give him a resource. Of course, work boils. And, by the way, the release will be pretty fast. Do you know why? Perhaps, even after the first weekend, the intern will write something that can already be clicked and watch the program perform what is usually done daily, in 10 seconds. Fast code, the goal is clear, the interface is not particularly important, tests somehow later. Bright future.
Furor. At this moment the baby mammoth is born. He is small, fast, all the fun and cute jumps from the negotiations in the negotiations.
Usually, at this stage an assumption is made about how to develop the project:
1) “Serega, you will cut the software 50% of the time” - “Ok, boss”.
2) “Keep the code locked up. This is our Unique Technological Advantage. To competitors Nini "-" Ok. "
3) “They drank the functional, do not care about the appearance, it's purely for work” - “OK”.
Time in the company runs pretty fast, year after year. 2006 is replacing 2015. 2015 is replacing the 2024th. Serega quit long ago. The mammoth is already hard to squeeze between the ceiling and the floor, in addition to preparing reports, he lured away a hundred - other corporate functions.
At that moment, when one of the interns found a self-hosted counterpart on the githabit, which was written in React + Rails with Flat Design. Or maybe someone else’s sales crept in and sold it to the SaaS director. Or maybe someone from the company went to the conference and heard how these problems were solved with the help of a plug in the google drive ... In other words, he died when people saw that there are excellent tested analogies in the world that solve the problem much better. .
As is customary in business, "work - do not touch." To translate, this means that the mammoth will be used for several more years with a gradual migration to the newfangled find. And yes, resources for its update will be allocated very little. They will be frightened by interns, and former employees on corporate events from competitors will amuse and delight colleagues with stories about their user experience.
Yes, technology replaces one another. But there is an opportunity to develop something within the company with an eye to the future, and not to the present. And there are some very successful examples.
Let's admit to ourselves honestly, there is simply no one Unique Technological Advantage in 99% of internal developments. In most cases, typical solutions are not suitable for companies that have built a cunning and rare business process and they begin to cut their own, so that IT fits closer to the conveyor. Stop panicing that competitors will steal your system. This is possible, but try to assess this risk soberly. Most likely, competitors from other cities and countries, markets and niches will start using software. And most importantly - they will begin to improve it. From open source you can get real and tangible bonuses:
Start your internal development as if you wanted to sell it. And yes, sell immediately. This will set a high level of quality, will allow to detect holes in the business process and scout competitors, get a ton of valuable criticism, it will give a good assessment of the product in hard currency. At any time when a colleague says, "What a damn fucking thing we have left!", You can ask, "How many copies have we sold?". And the answers to the question “Why so little?” Can reveal the most bizarre mistakes in understanding and building a product now, and not “internal” software.
When a company develops something for itself, it often stores it in the dungeons like the apple of an eye. Software becomes obsolete. It becomes outdated instantly and you need to constantly allocate resources for its development, refactoring, redesign, new integrations. It is very difficult to force yourself to do this when users are 3 people. Face your design with the outside world. The sooner you do this, the better. Perhaps the best feedback to your beautiful software will be: “Why didn't you take this thing, why cut yours? github.com/project_author/project_name ". It means that someone has already done your work. Do not be angry that you have wasted half a year for nothing, but rejoice that you did not spend even more.
Develop phoenixes that will be harmoniously reborn and bring benefits year after year without compromise, and not mammoths who will overwhelm the business with their bones. Or even do not mess.
I will try to tell that most people forget at this moment. It does not matter what they are going to develop - a library for cropping images, a framework, the most complicated plug-in for CAD or another cozy ERP-CRM. Think stop. Googled again, please. Perhaps you should not even begin.
')
An example that is familiar to most programmers:
A few years ago I came to work as a programmer in a small company. I got a computer assembled and a tech scan called me. Called to introduce him. It was a framework written in PHP 3-4 versions. Everything was fine there - and the storage of the executable code in the database, and the admin on the self-made bootstrap from the tables, and the database with the names "__123123". By the way, YII 1 at that moment was already gaining momentum, and Django began to get older. We did not care, we were busy with plans to port our internal development to the OOP PHP. Well, someday. When will the extra resource. That is, never. In the meantime, customers are waiting, you need to start on this framework 5 more projects. We have already signed TK.
I think every programmer has come across this phenomenon in his career. We recall with irony our naivety and blame everything on inexperience. However, this is not the reason. We are doing the same now. Constantly. We give birth to mammoths, who obviously, on the basis of their development plan, must die. And their bones will lie right in our office. Somewhere in the aisle for people to stumble. But these are our corporate bones. We, in principle, ourselves brought them here and thought at this moment with our head.
Birth
Let's return to our enlightened employee. He rolled away from the computer in a chair and decided to write software. I don’t know, probably, this kind of software for generating reports on templates. Or not. Probably, this is something that will allow to tear apart the TK on the issue in the task tracker with one click of the mouse. The authorities will give him a resource. Of course, work boils. And, by the way, the release will be pretty fast. Do you know why? Perhaps, even after the first weekend, the intern will write something that can already be clicked and watch the program perform what is usually done daily, in 10 seconds. Fast code, the goal is clear, the interface is not particularly important, tests somehow later. Bright future.
Furor. At this moment the baby mammoth is born. He is small, fast, all the fun and cute jumps from the negotiations in the negotiations.
Usually, at this stage an assumption is made about how to develop the project:
1) “Serega, you will cut the software 50% of the time” - “Ok, boss”.
2) “Keep the code locked up. This is our Unique Technological Advantage. To competitors Nini "-" Ok. "
3) “They drank the functional, do not care about the appearance, it's purely for work” - “OK”.
Time in the company runs pretty fast, year after year. 2006 is replacing 2015. 2015 is replacing the 2024th. Serega quit long ago. The mammoth is already hard to squeeze between the ceiling and the floor, in addition to preparing reports, he lured away a hundred - other corporate functions.
Death and funeral
At that moment, when one of the interns found a self-hosted counterpart on the githabit, which was written in React + Rails with Flat Design. Or maybe someone else’s sales crept in and sold it to the SaaS director. Or maybe someone from the company went to the conference and heard how these problems were solved with the help of a plug in the google drive ... In other words, he died when people saw that there are excellent tested analogies in the world that solve the problem much better. .
As is customary in business, "work - do not touch." To translate, this means that the mammoth will be used for several more years with a gradual migration to the newfangled find. And yes, resources for its update will be allocated very little. They will be frightened by interns, and former employees on corporate events from competitors will amuse and delight colleagues with stories about their user experience.
How else? We are doomed
Yes, technology replaces one another. But there is an opportunity to develop something within the company with an eye to the future, and not to the present. And there are some very successful examples.
Open source. Immediately. From the first day
Let's admit to ourselves honestly, there is simply no one Unique Technological Advantage in 99% of internal developments. In most cases, typical solutions are not suitable for companies that have built a cunning and rare business process and they begin to cut their own, so that IT fits closer to the conveyor. Stop panicing that competitors will steal your system. This is possible, but try to assess this risk soberly. Most likely, competitors from other cities and countries, markets and niches will start using software. And most importantly - they will begin to improve it. From open source you can get real and tangible bonuses:
Free testers
High quality code
A large number of fashionable open source projects adheres to a high programming culture. There are tests, CI, code-review. Developing a high-quality product in the conditions of such reasonable quality competition and openness is easier than alone with yourself locked in a corporate repository.Image
basecamp.com/open-source is a link to the page of a small company that has developed Ruby on Rails. If the RoR programmer, other things being equal, will choose between her and something else, the choice will be obvious. This is just an example. The topic is much broader.Employee Motivation
A programmer who writes open source usually understands that he is writing his resume at the same time. This can serve as an intangible motivator for employees who work on internal development. They can continue to work on the project at another place of work, completing features already for competitors. But most importantly, your mammoth can become a phoenix and live much longer.
Lean startup
Start your internal development as if you wanted to sell it. And yes, sell immediately. This will set a high level of quality, will allow to detect holes in the business process and scout competitors, get a ton of valuable criticism, it will give a good assessment of the product in hard currency. At any time when a colleague says, "What a damn fucking thing we have left!", You can ask, "How many copies have we sold?". And the answers to the question “Why so little?” Can reveal the most bizarre mistakes in understanding and building a product now, and not “internal” software.
Epilogue
When a company develops something for itself, it often stores it in the dungeons like the apple of an eye. Software becomes obsolete. It becomes outdated instantly and you need to constantly allocate resources for its development, refactoring, redesign, new integrations. It is very difficult to force yourself to do this when users are 3 people. Face your design with the outside world. The sooner you do this, the better. Perhaps the best feedback to your beautiful software will be: “Why didn't you take this thing, why cut yours? github.com/project_author/project_name ". It means that someone has already done your work. Do not be angry that you have wasted half a year for nothing, but rejoice that you did not spend even more.
Develop phoenixes that will be harmoniously reborn and bring benefits year after year without compromise, and not mammoths who will overwhelm the business with their bones. Or even do not mess.
Source: https://habr.com/ru/post/294526/
All Articles