How to survive before deadline

Ann Krepchenko
AndroidPub
Published in
4 min readJun 3, 2017

It’s not a technical guide with code you can copy/paste and survive. It’s my story which I believe will help someone. 😊

Pre-condition

3 Android developers.
1 project with 2 applications.
Each of the application can be built on one of 2 flavors to switch between communication protocols.
No docs at start point.
Base protocol to extend from.
1 project to extend from (need lots of modifications and rebuilding to flexibility).
1 and half months to finish.

That’s all. And we had started.

Main part

I started with the developing protocols of communication. The difficulties were faced:
- supporting transferring the same data via WiFi and Bluetooth,
- supporting communication with server and another hardware device.
And my guys started with implementation of flexibility into the project we based on and switching to another server. Working on my part, I found that all my estimates are too small -> I was discovering more and more hidden things we should do.

Advice: write some docs about architecture​ and protocols before you give last estimate. And do not edit an estimate on call😂

Then I started to develop 1 of application with protocol based on Bluetooth. Too easy, you can say. Haha. Nope. “Let’s write app on Kotlin”, was in my head. Whaaat? I have some experience with Kotlin. But my team haven’t yet.

It wasn’t a problem, really. But it was a great force to learn Kotlin. Now it gives us a speed up in development.

Advice: do not afraid to use new solutions.

Advice about previous advice: use them if it really HELP you and you are believe in yourself and your skills.

After that I had prepared some more detailed docs according protocols, databases, etc.

Advice: do not answer questions, review pull requests with absolutely different functional, help someone with architecture part when you are writing important docs.

All this stuff in advice I had broke. And this mistake cost me 4 fuckups in docs. Please, don’t do this in real life☺

The worst part of this story. I have one week vacation in 1 and half week after the start point of the project. Thats why all solutions were taken in hurry, all docs were written in hurry, all code was checked in hurry.

Advice: don’t hurry up if you are working with architecture part.

Of course, I was jumping the gun before my vacation. I wanted to leave all my stuff done, docs prepared and keep my guys in safety.

Then I built huuuge logic of synchronization between server, mobile and hardware device.

Advice: keep in mind all details of your project. It will help you to find mistakes quicker and answer all questions correctly.

We should give this logic chance to become alive. We had 14 days before deadline and a lot of work with data transferring​. The best solution was to use Rx. My team had general experience to do simple tasks. Do you think it makes​ sense to work using trusted ways? Nope, I chose Rx, without any skills to build big infrastructure.

We implemented RxKotlin into one app and RxAndroid into another. And it looks pretty nice now. It can help us to develop faster and do only work we need, without any useless parts. It was measured solution.

Advice: if you think about correct way to do your stuff and you are afraid you have too little time, write down all advantages and disadvantages to every way.

Conclusion

Keep calm, believe in yourself and you will be able to build great applications in time.

Now we have only 7 working days to finish our current tasks, implement second protocol to both of applications, connect them and fix bugs. Wish us good luck!

P.S. I want to say big thank to every team member for your work and a special thanks to the PM who helps me to solve all issues.

--

--