I’ve been through teams dedicated to new projects built from the ground up. I’ve experienced failure, disaster and success in these projects.
The success, which came eternally, resulted due to the learned lessons and experience which I will deliver in this post.
The Team’s structure
The Tech-Lead: who will set the design in order to fit the deadline and the customer dynamic requirements and start the abstraction, testing platform and infrastructure of the project. Moreover, should keep tracking the pulse of the requirements with the manager and the project manager.
1-2 Experienced developers: Depends on the size of the project. Taking into account that the Tech-Lead happens to be the lead developer, then one more developer will suffice.
The Junior/s: Helping with maintaining the E2E testing, DevOps and the Compliance.
Study the facts
- The stakeholders part requires a great deal of devotion: who are they? what is the scale? what’s their goal from using the system? what are the requirements and for how long? How much dynamic and flexible the requirements are? How they will reach the product?
- Trying to study the competitors could save us a great deal of time learning from their failures and analyzing their best practices.
- What are the product future image and long-distance goals?
Understand what’s in the domain
Understanding the requirements and the goals of the stakeholders will put the product on the same track. Understanding the competitors best practices will chart the territory of failure so it can be avoided.
Demo and the Quicksand
Anyone can write a code that works. you can find hordes of them in any cube farm. Getting it right is a whole different case.
I remember a time when I started the Friends Location, who happened to be sort of a new idea. I was to publish it As soon as I can to impress my users. I’ve got it working and published it to google play.
Several months later, I wanted to add some new features. It was impossible to commit anything without destroying something else – the programmer hell. I was swallowed deep in the quick sand.
What went wrong?
1. I had to acquire the right skills to get the design right. Such skills require a great deal of dedication which any young developer lacks.
2. My prioritization for what is Urgent and what is Important was incorrect.
Charting the loose sand spots
I had to understand the two greatest value of software:
Behaviour: This is the Urgent value of software.
Architecture: This is the Important value of software.
I should have prioritized as follow:
1. Urgent and Important
2. Not urgent and Important
3. Urgent and not important
4. Not urgent and not important
The architecture should be considered in the first two stages while the behaviour comes at stage 1 and 3.
The behaviour concerns the stakeholders is urgent and there should be a demo ASAP to better track the advancement. Usually, when you ask the project manager about the how to prioritize the architecture, they will put it last, thinking that the stream of requirements could be applied with minor modifications. However, reality is different. Relying on future refactoring is not an option as the requirements stream will keep flowing. Making such refactoring a fictional goal.
I was surprised when I follow a well designed and TDD(Test driven development), a less time was required to accomplish the first demo.
The first version of Friends Location took me almost a month. However, after starting from the ground up with the right prioritization, it took me almost 15 days.
Organize and Recommend
Now that the development team ate able to visualize to the stakeholders their wishes, it is the time to tackle new requirements and improvements.
With the right design, now further work force is needed. By this, the development team saved a big deal of money to the stakeholders.