Custom software development is something I've been doing for many years, most of which has been a job for hire. But some time ago I decided to try to do something kind and, to the maximum, durable on my own.
Often cool ideas can only be realized when my end user and I have the opportunity to set our rules and priorities, when there is no need to take into account the personal interests of numerous gaskets and damaged phones between me and the end user of my product in the complex hierarchy of a large organization.
Although I also treat the wishes of end users in a special way, I do not ask users what they need, I remember Ford's famous quote: “If I had asked my customers what they wanted they would have said a faster horse.”
I ask users about their problems as a doctor. Patients do not have to know what medicines they need, the doctor knows better about medicines. It is enough for patients to describe their problems.
When developing custom software, I try not to "reinvent the wheel", but to make the most of already created industrial solutions, third-party libraries and my own developments.
The consequence of the previous paragraph is to integrate more, encode less. If you have an old system that, by and large, suits you, but it lacks any functions, it is not necessary to throw it in the trash, and implement a new system with new functionality. It may be easier to make an additional module with the necessary functionality that can be integrated with the old system. Thus, it is possible to achieve a quick result with the least risks and costs.
For example, one recruitment agency kept records in MS Access. And somehow they were not satisfied that the applicants' questionnaires had to be manually entered into their system, and they wanted to transfer all the functionality to the WEB so that the applicants themselves would fill out the questionnaires not as they want, but strictly in accordance with the requirements of the web form. Over the years, they have written quite a lot of functionality for themselves in VBA Access. Redesigning the system on the web would take a lot of time and money, and money is something that the customer, unfortunately, is very reluctant to part with. Well, I suggested to them: since you need applicants to enter questionnaires themselves through a web form, and everything else, in principle, suits in MS Access, let me make this form for you on the web and integrate it with MS Access. It will be cheaper, and you will not have to retrain for another system. That was settled.
Or some cloud service offers its API for calculating a lot of things, for example, it offers a solution to the traveling salesman problem on its maps. Yes, their service costs money, but sane, my development from scratch will cost more. So why not use their service for a quick and high-quality solution?
In most cases, clients initially set tasks in a very vague form, while requiring a potential contractor (for example, me) to accurately assess the timing and cost. In such cases, many contractors are heavily over-invested in the cost and timing of development. I don't like to overestimate.
I act differently. I am trying to persuade the customer to divide the task into several phases, each with specific deadlines and work results. Each result of the work must be confirmed by specific test cases. When we agree, we work. If we don't agree, we don't work.
In general, the phases are as follows:
- Preparation of the customer's "Business Requirements" document
- The description of existing business processes "As-Is" is what the processes look like now
- Description of business processes "To Be" - how the processes should look after automation
- Preparation of a high-level specification of the solution, in fact, a technical specification in the customer's language, which reflects the criteria for project acceptance, i.e. an exhaustive list of testing options. Within the same stage, a project plan is being prepared, the cost and timing, the scale (what we will do) and exclusions (what we will not do) of the project are being agreed upon
- Actually, the development.
- Pilot operation, user training.
- Support for the created solution.
Throughout the project, project documents are created that allow the customer to be aware of what percentage of the total amount of work has been completed, what problems have arisen during the work on the project, what requests for changes have appeared, etc.
Yes, detailed documentation costs money, but it also reduces risks. I prefer to be confident in the results of my own development, and I want the customer to also understand what is happening. I also believe