I’ve noticed that many software companies are fixated on their development process. They follow it mindlessly and thus treat every client the same, no matter how big they are – Bank of America or a local grocery store – according to THE PROCESS.
It’s good to have procedures that help us avoid disorganization, but treating the process as sacrosanct forces the client to adjust to us and – correct me if I’m wrong – it should be the other way round. Clients are different, have different needs and budgets, and we as architects should make the best of it.
How it works in skygate
In skygate we truly believe that there are no ready-made solutions and processes suiting every client. We understand that not everyone has a six-digit budget and years to wait for the perfect final product.
What solutions, language, hosting or server we will use is secondary and results from the business requirements only. To adjust to the client and their needs, and not realize internal processes – this is what I call true Agile.
What client wants and how we provide that
Client wants to build an application that does 3 things:
1. Realizes business aims
Above all, every commercial product has to realize particular business goals. The use of the state of the art technology, most sophisticated framework or the newest programming language may be fun but not essentially serves the aim. Thus, we pick tools that suit the project – not us.
We also try to bring client back to reality when they want to realize some crazy idea that does not foreshadow a happy ending. Contrary to popular belief, the customer is not always right and we need to educate them not only in terms of technology but also business aspects and costs of software development. For example, our last client Lannock wanted to build big application at once, but we’ve advised them to divide it into steps, MVPs. In this way they will get core of the application quickly and cheaply so we can develop it further.
Secondly to realize business aims an application has to work. Sounds obvious, but believe me when it comes to software development nothing can be 100% sure. To make certain that the application works we run automated tests and configure failover policy. To ensure overall stability we use several different monitoring tools such as Sentry or New Relic. For each project (if there is such a need) we also develop own tools that will help to monitor the infrastructure. After we’ve introduced automations based on Amazon AWS for our client Manduka, the biggest producer of yoga equipment in USA, their downtime has dropped from several hours practically to zero.
3. Ideally, doesn’t cost too much
And I don’t mean here it is cheap, because good and cheap don’t go hand in hand. It means that our aim is to create the best budget and project possible. On the one hand it means we can’t promise pie in the sky in small budget, but also we shouldn’t spend whole budget if it is not necessary to have a working application that realizes client’s aims.
The awareness of business aims is essential among developers. Many may disagree, but I think this is the first thing the guys should know before they start any development work. The team also needs to keep in mind that the business requirements can change during the project lifetime because this is the specifics of the startup environment.
3 dev flow scenarios
Every software project is preceded by customer needs analysis and the decision what is the scale of the application. Depending on the type of project and its plans for the future we distinguish the following 3 scenarios in skygate:
1. Forever small
This is a small project that will remain small, such as a landing page or an MVP that is just a proof of concept and won’t be further developed. In such a case we assign 1-2 devs, leave out architecture planning, automations, advanced system settings and integrations. We narrow the budget down and don’t include functionalities that are not essential.
Actually, this scenario very rarely takes place in real life. Even though the client says we can reduce expenses because the app won’t be further developed… later on they want to develop it anyway. It happens like that because on the surface the app works and the client doesn’t see the technical debt inside.
2. Small to grow big
This is a small project that will be further developed or we don’t know what will happen with it in future. In such a case we need to pay particular attention to business requirements analysis and budgeting with aim to create economical app but suitable for further development.
It has to be written quickly and cheaply, but at the same time professionally and with clean code – thus it is more time-consuming than the first scenario. All the time we need to keep in mind that the architecture will be developed further, so it needs to be solid. Our aim is to minimize the technical debt, although we can create some (we will deal with it later). Because the budget is limited we build tests but only to cover the critical points.
From our experience this is the most common scenario especially in startup environment. We start with MVP to prove the concept and get first clients and ideally funding, then develop it till it reaches all functionalities. This was also the case of our client Expert Knowledge, who is currently building their own development team after we’ve build an MVP with them.
3. Designed big
This is the application designed big or enterprise size from the very start, such as our app for eSky. The client quite precisely knows what they want which gives us as architects a chance to see the big picture – where we stand and where the whole app could go.
We analyse if it all has sense and, if does, we do our best to follow the project documentation and oversee all possible scenarios when software architecture is considered. We plan architecture and how the application will be created: domain, focused on efficiency or big data – these are completely different approaches.
In this scenario first software architect enters, defines the whole architecture, continuous integration, continuous development and QA processes included. S/he creates the basis for production – it all happens before any developer starts coding.
To conclude, We’ve got no ready-made solutions and processes, but all are based on the analysis of business requirements and the infrastructure needs.
No matter which of 3 scenarios you start with you need to remember that client’s requirements may (and most probably will!) change in time. They can earn money, get funded or pivot. Thanks to the true Agile approach described we are ready for that.
Hope to hear your thoughts on that.