This article is about the software development life cycle in a business and money language. Many headmen of projects expect short and simple answers on complex technical challenges, and can't receive them. At the same time, all projects are technically similar, and the solution to most of the problems is generally known.
In this post, I summarize my experience of communicating with the leaders of different companies, when short phrases were not enough. I hope this post will help business people and engineers better understand each other.
Once upon a time a man talked to a construction foreman. The house a man lives in with his family was made of bricks. Laying on a ground cemented bricks made walls. There was one problem two men were talking about - walls tilt. Propped up with sticks, walls tilted more and more, and a man was worried that the house would collapse sooner or later.
"The house requires reconstruction," said the foreman. "Here's what I offer to do: carry in the power line to power the construction equipment, dig the pit, make drainage, fill the foundation…"
"Oh, no!" a house owner interrupted the foreman, "I need the House! Walls! Not a pit!"
"Maybe you should consider buying a modular house?" offered a foreman.
Our days
Last month I talked to a startup. It has a web service being coded for several years, and now they need to do something with it. Founders told me their plan to hire about 10 programmers to rewrite or refactor the system. I asked if they had user stories, documentation for API, task management system, and they don’t. They asked me to write a list of what I consider they should do, and I wrote this:
- List key parameters affecting sales of the product: SLA, features - anything to bind the virtual tasks to the real world.
- Study the business logic, define contexts by DDD, and create a high-level description to assist onboarding of new developers.
- Define the system bottlenecks that make problems with scaling and availability
- Agree the middle-term goals of an IT team with stakeholders.
- Establish a hiring and onboarding process.
- Create a workflow using team collaboration tools such as kanban boards, ticket/tracker system, chat, git repo.
- Set up system monitoring, logging and backup/recovery plans.
- Decompose the middle-term development goals by milestones and agree calendar plans.
- Create a CI/CD development-test-release flow.
- Write the architecture modification plan.
- Prioritise tasks in the backlog.
- Work out the regular meetings with a product owner and reporting to stakeholders.
But where is the development in the list? The answer is: all of this. Development is a complex process, it is not just coding. It is a Systems Development Life Cycle (SDLC).
Founders of the company told they doesn’t need management, they look for someone who codes. Thank you guys for your feedback, cause I it made me feel I should write this article and explain what development is. Everything in the list is related to money.
How each element in the list is related to money.
- Key parameters affecting sales - traffic, retention, etc. We all love R&D, discuss the culture of coding, but evaluation of IT companies is a multiplication of a revenue or user base by some factor, and the code is not taken into account at all. I believe the work should be bound to measurable parameters used to set goals for technicians. It is important for the key parameters to be named and tracked. I was involved in a lot of projects, and saw how managers of a couple of growing projects ignored significant changes of key parameters. Ignoring changes ruined projects in just several months after years of hard work. Despite being technically reliable and still make some money, projects lost the market, and could not recover. I remember the opposite situation at Oracle Corporation. Everyone was told how many millions of dollars of revenue the product we worked with earned, the market share, how many new customers came, how many left, competitors, and so on. There were common meetings for all staff where VPs presented the report they made to the board. You can see by Oracle's financial results this concentration and involvement works well.
- Studying the business logic of a project is an essential part of hiring new employees. Defining contexts is required to make people understand each other and define areas of responsibilities. Investment in general high-level documentation pays off with each newcomer salary.
- Bottlenecks are the technical problems that prevent achieving goals by key parameters. They need to be addressed in the backlog and project plans.
- Middle-term goals is what the company pays programmers for. It is not vital to have the middle plans written, but absence of middle-term plans usually means that developers play in research and fight for coding standards of their preference.
- About hiring. Everything in a project is done when people are hired. The cost of onboarding is the sum of salaries of employees
involved in learning and teaching, plus the lost profit from the tasks
not implemented during that time. Large enterprises may
afford months of onboarding, but most projects need programmers to join
as soon as possible. Should hiring be a process, or the top management does it with irregular interviews depends on plans to scale business. Startups change fast. Testing new markets and scaling require different people. Intensively growing startups need the hiring process run with minimum top management involvement. Whether a company treats hiring as a regular process or as a finite task is a simple indicator of its plans to grow.
- A development workflow with boards, tasks, code repos, daily meetings, building, testing and deployment is essential for most teams. We just can’t have features deployed predictably and keep uptime by SLA without the software development lifecycle.
All tools are ready-made, one can set them all up in a couple of days, they are free or cheap. Jira or Clubhouse, Slack / Element / Riot / Skype, Github or Gitlabs, Jenkins / Actions / Jobs, Docker with Registry, Swarm or K8s, Sentry / Rollbar / Logstash - everything is already done, just choose and apply. - System monitoring, logging and backup/recovery plans is not the first task you do when deploying the MVP. It becomes essential when the project starts burning money to attract customers. Everything breaks sometimes, and the bigger the budget grows, the more important it becomes to keep the system available for the cash to flow. Setting up backups and monitoring is not a management decision, it’s an essential way to decrease downtimes.
- Decomposing the middle-term development goals by milestones and epics is required to follow the process, predict the results and intervene when the problems appear, not waiting until it is too late.
- The benefit from a CI/CD development-test-release flow is not obvious. By Lehman's law the complexity of software increases while it evolves, unless work is done to maintain it. CI/CD is the developers’ part of efforts to control the complexity growth. Covering the code with tests, and running them in the dedicated build phase curbs the development budget growth. It's OK to live without it, you will just grow slower, cause you need a QA team of the same size as development, doubling office space, accounting, and quantity of managers in meetings. This task is not at the top of the list because it makes sense only for successful and actively developed projects. For average projects deployment from a release git branch works well.
- The architecture modification plan is one of the most important tasks to speed up the development of the features that seriously impact the business, and scale it. This plan helps prioritise tasks, cutting off not important ones. I place it in the bottom of this list because it is not crucial, you do not need to keep the system working. We need it when we have ambitious middle-term goals and resources for them. This is not a part of management, this is an architect role.
- Prioritizing tasks in the backlog can be done differently, and there is no one true way for all. In SCRUM it is done by the team with an opinion from a product owner. In traditional workflows priorities are defined by a team lead. In a gull-style management it is not defined at all. It is more comfortable for people when they know the rules for setting the task priority. When people know the rules how priorities are defined, they learn to do more important tasks to feel themselves important.
- Regular meetings with management, reporting to stakeholders and attention lets people feel right, being a part of something, helping teams survive crises.
How much does it cost to do a startup?
So, how long will it take to implement a project? Most likely, the answer should be some kind of "Use Wordpress, as 38% of internet web sites do". In many cases you can avoid in-house development. Use a SAAS, a ready-made package, outsource it, get the total cost of a finite solution, and a calendar date in a contract. Unless you are doing business in IT, of course. By Lehman's law, the functionality of software must be continually increased to maintain user satisfaction over its lifetime. To compete in the market the development of the software never ends. When the project grows there are more operational, business analysis, management and architecture tasks added.
What if you just code without all those CI/CD, repositories, trackers, just make calls and discuss? Well, maybe programmers will understand you and make the software that does what you want it to. Or maybe you will have to fire and hire several development teams and rewrite the software several times. The difference is in predictability of results.
