Assumptions-driven development

It’s quite hard to admit, but recently I have almost entirely failed with initial design and implementation of one of the features needed in software on which I am currently working. It’s even more challenging when I have a meaning about myself as pretty established, experienced developer. This "almost fail" leads to me to the fact, that there is always something new to learn and there is still need to open question even for the easiest problems.

Assumptions are bad

All this story and throwing away my two-week work (almost all) started with the lack of communication, my assumptions and vague description of the task. Even when I have opened some questions, they were answered a little bit vaguely and without the thorough understanding of respondent. Also, documentation was very broad and almost only about the product itself, not so many technical details about affected area. And documentation inside codebase? Just hard to use or undocumented code. So I started to think about “how this and this part of software works” on my own by looking at documentation and to the code, test codebase and (of course) debugging. By the way, I agree with Yegor, if you are debugging something, it is a sign that is something wrong.

Fail trajectory

I have collected all errors bellow:

Fail 1: As the codebase were pretty large I have created own assumptions, own mind maps about the parts of the architecture.
- Then I was trying to invent solution passing to my understandings of code. Ultimately wrong.
Fail 2: I was presuming that is expected to understand all the code with the only slight help of others as others seemed to be very busy.
- And probably as my ego was big enough for fighting the task alone.
Fail 3: I was too early convinced that I can come with the reasonable solution and immediately start working on the proof of concept (POC).
Fail 4: After I designed the POC and proven that might work I was not diligent enough to discuss my solution with a broad audience if the solution fits the architecture, further development or future features.
Fail 5: As my POC confirmed that it can work I started working on implementation details in one part of the application before scanning all of the affected areas.
- And not surprisingly in two code areas, it was very hard and wrong by my design to incorporate my design into these parts of the codebase.
Fail 6: After some pressure had come, I avoided working in Pomodoro’s style to achieve “better” productivity and after a whole day of developing I was just so overwhelmed.
- The big picture immediately went away. Productivity was even worse. My personal feeling was bad as well. One positive point is that I realized that it’s not working quite early and returned to Pomodoro’s after one and half day. At least something.
Fail 7: I didn’t make an analysis of all technologies used in the project and how can be replaced or utilized better.
Fail 8: Code review was not done periodically on small amount of code but on the code produced after two-weeks development.

How it ended?

On the end, it was a success. But more than three weeks work in addition to two weeks spent on the wrong implementation. Beginning of the success started mainly due to my personal self-retrospective by my opinion. I am doing it for more than for months and after the second week and revisiting all the work done, I realized that I wasn’t able to deliver something feasible in two weeks, and it’s just wrong. Then I was communicating with others more thorougly; I was organizing sessions with opened development environment, and I was deeply analyzing all the suggestions. I returned to the implementation after three days of communication, meetings and with clear steps defined to achieve the goal of my task.

Suggestion for all developers

If you are self-reflexive enough, you can reckognize one of the fail above which all started with my assumptions over knowing. The point is to realize this fail fast to avoid unnecessary work, throwned code, and frustration. You are not alone and not working alone, there is always someone to ask, to discuss possible solutions deeply and getting rid of fails mentioned above. Be more experienced and mature developer by not using assumptions driven-development!

P.S. If you enjoyed this post, you can follow me on @mikealdo007 to stay in touch with my articles and other thoughts.

P.S.2 Cover image by Tomas Salas | unsplash.com.