This is the first blog post from Reliable Dev. And it will tell you why Reliable Dev was founded. And what value it may bring you.
If you are in software development industry I am sure you have heard about all the horrors of software outsourcing. And for those unfamiliar with the matter I will provide a brief overview now.
Software development in general is quite challenging. According to CHAOS report 2016 analysis (1) only 29% projects are successful. And 71% are challenged. What's even worse is the fact that there was no improvement since 2011. Numbers over years are about the same. They are slightly better than numbers from 1995 (2) but still, projects are more likely to be challenged than successful. And the larger the project - the bigger chances of failure. Doesn't look promising, eh? Murphy's law is very strong in industry.
And that sad statistics was about IT projects in general. Outsourcing imposes additional challenges. Communication challenges, specifically timezone and cultural difference, are the biggest. Timezone difference leads to delays. Cultural differences lead to misunderstanding, which in turn leads to wrong implementation, and again delays.
Now here I am, created Reliable Dev to help businesses avoid all those software outsourcing problems. And I focused on 3 components that improve success rate. Let's take a closer look at these parts.
In-depth business analysis
Unclear requirements is named the biggest software outsourcing issue in many sources (3). It is an issue for in-house developed projects. The question of how much requirements should be broken down sparkles debates on the internet all the time. Many managers prefer to provide very high level requirements and let engineers figure out the solution without limiting their creativity. While it works for in-house projects to some extent, offshore developers usually have too different background to understand high-level requirements. But with offshore developers this becomes even bigger problem. Businesses operate differently in different countries. Some businesses are not widely present across the globe. Other cultural differences kick in. So offshore developers in general would have more questions than local developers. Good developers ask you questions about requirements they don't understand. But they can ask only so much, especially when they are in a different time zone, and you don't have full 8 hours of overlap. At the end of the day they need to deliver a product on budget, and they have to do something while waiting for answers.
To address this Reliable Dev provides in-depth business analysis and helps companies with requirements development. We start with high level requirements, identify user stories and jobs to be done. We explore each story carefully, search for edge cases, define acceptance criteria. Capturing edge cases and exception paths is very important. Handling of these scenarios may constitute a large chunk of work. If these requirements are not identified they will be missed during estimate. Which in turn will lead to time and budget miss.
The process described above reduces misunderstandings, and minimizes idle time when developers are blocked due to unanswered questions. And there is no developer creativity limitation here. Eventually all requirements are discussed with development team. Starting from high-level requirements and digging down into details. Developer feedback and suggestions are always welcome.
Full Devops process
"DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably." - quote from Atlassian (4). That's exactly what we need.
There is no set specification of what exactly Devops process include. It evolves rapidly, but what's more important each project has different needs. Here is the generic Devops process breakdown (5):
Plan. Answer question what is being developed.
Create. Answer question how code is actually written.
Verify. Answer question if developed code satisfies requirements.
Package. Assemble all development artifacts into releasable package.
Release. Automate and streamline releases.
Configure. Answers question how actual deployment is configured.
Monitor. Understand impact on end-users.
Fortunately some parts of this process are widely adopted. Planning, creation, monitoring tools are used by most developers out there. Not always perfect, but better than nothing. Verification, packaging, release, configuration are somewhat adopted. But without these tools long-running projects involving multiple engineers get impeded very quickly. Automating interaction inside development team is crucial. The bigger the team and the longer the project runs the more sophisticated tools are required.
The usual excuse from outsourcing agencies of not doing some parts of the process is that the customer does not pay for it. Which is fine for short-term projects that don't involve many developers. And opposite is true for projects that involve multiple developers. Skipping parts of the process results in additional delays costs. Far bigger than initial savings.
That's why Reliable Dev establishes process and helps developers follow it. We admin full suite of tools to accommodate project needs. This allows to have clear picture of what is going on to all members of development process. Both customer and developers. Another nice outcome is that development process setup is not tied to development vendor. It belongs to customer. And if development team changes, for example customer moves project in-house, whole setup and history are preserved, and transition is smooth.
This is the 3rd crucial piece. Everybody agrees that quality is important. But term "quality of software" has two different meanings. First is from user perspective, how software serves user. And second one, how good code is, how flexible and maintainable it is. Making sure that delivered software satisfies business requirements is a widely adopted practice.
But second quality is not always there. Non-flexible, non-maintainable software is faster and easier to create. But you can see the issue here. When new features are added it becomes hard to accommodate them. So if software is not meant to evolve (MVP for example) this approach is fine. But not for software with long life cycle. Development speed degrades over time in all projects. The question is how much it degrades. There is a term for that - "Technical Debt". The more technical debt is accumulated the higher cost of change is. You can imagine what happens to project that must evolve but cost of change is significant. Rewriting from scratch is expense too. History knows examples when projects and companies died because of technical debt. Actually this is the most likely reason of failure for projects with clear requirements. It is not big in overall statistics because many projects fail on the way to initial release. I would say that flexibility and maintainability should be a part of business requirements, if business expects to develop software beyond initial release.
This is what quality review addresses. At Reliable Dev we make sure that delivered software is not only good looking from user perspective, but it also good enough inside to accommodate future improvements and new features. Automated tools from the previous part help a lot with this task. And humans add final touch to make sure that chosen technologies, core assumptions, general patterns match project needs and industry standards.
One more thing
I'd like to talk about one additional benefit that comes with all these services as a bonus. Increased bus factor, and vendor lock-in prevention. Nowadays developers tend to switch companies pretty often. For project running over several years it is totally fine to end up with completely different team members. And avoiding delays when developers leave project is crucial. Vendor lock-in is more dangerous. Sometimes outsourcing providers do it on purpose for their own benefit. We don't work with such companies. But even with fair companies it happens. And if vendor has to be changed for whatever reason, all components are there to make transition as smooth as possible. Customer has all project artifacts, setup environment, standardized processes and practices used widely in industry. Thus another dev team may pick up project seamlessly.
That's all for this post. Hope you enjoyed it. I would like to hear what you think about ideas I described here. Does not matter if you agree or disagree, let me know. If I got your attention, and you are interested in services, that's awesome, reach out to me. If you feel the opposite, still message me, I would like to learn more.
My next goal is to share more detailed analysis and my take on Reliable Dev core components. Stay tuned!
I say "we" sometimes referring to Reliable Dev, but as of today when this post is written Reliable Dev is a one man agency. But I plan to expand it, this is why I use "we".
CHAOS report 2016 analysis https://www.pmiwdc.org/sites/default/files/presentations/201703/PMIW_LocalCommunity_Tysons_presentation_2017-02.pdf
CHAOS report 1995 https://www.projectsmart.co.uk/white-papers/chaos-report.pdf
The 6 Most Common Software Outsourcing Challenges https://www.sourceseek.com/common-outsourcing-challenges/
Devops: breaking the development operation barrier https://www.atlassian.com/devops
Devops toolchain https://en.wikipedia.org/wiki/DevOps_toolchain