Status update & Brain dump
I have to admit I am not really much of a blogger and I just realized that my
last post is already ancient, so here comes a little status update and a
personal brain dump for the interested.
What happened in the last months?
Well it has been a time of real ups and downs. A lot of motivation (ill guided
at times) and none at all. Good team work and non at all. Somewhere in October
last year I realized my motivation is dying, so I decided that our most
important priority must be to get the Android app out there - we need to reach
more users and we need some income. Firstly because, well, one needs to live from
something and second to get some validation. Are we building something people
want? Will people be willing to spend money on it? So we got going, and made
really good progress. It was actually far easier to get the Android version done
than expected. But then, well Robert happened: I had some great ideas for
revolutionizing the architecture of Gonimo and started working on that. As always, I
underestimated the needed effort by a ridiculously high factor and something I
thought, I might get working in like 3 weeks took me 2 months and wasn't even
finished then. You can have a look at the results in
the
reflex-backend-tryout branch,
which has about 90 commits that will never get merged. I designed a new protocol
for Gonimo (server - client communication) which centered around the idea of
just synchronizing state. I am actually pretty proud of that work, it became a
nice architecture and it is very well documented. But I then realized that it
wasn't all roses, it had it's drawbacks too, also it became apparent that the old
architecture wasn't that bad in the first place.
Also you don't get anywhere if you constantly rewrite everything, you got to
make small demand driven incremental changes. That's not rocket science, that's
actually common practice and I knew that beforehand. I learned quite a bit about
Scrum and I really liked it, but living it in practice is an entire different
beast. If you do stuff incrementally, you end up with a lot of work that seems
wasted. Why should I implement that step, if I know already that it is only
temporary and will get removed in the near future? Why even bother finding the
next small step in the first place - that's not an easy endeavor either. How do
I get changes to be small and incremental? They are not born that way.
It is of course not wasted work, because it avoids running in the wrong
direction for too long. If you take the effort to make changes small and
contained you get early reward and more importantly constant feedback, from
users and from yourself.
But I had to learn that the hard way. I had to waste almost two months of work,
at a point in time where motivation was already dying, to realize how to not do
it.
I am really grateful for that experience, because it changed me. I took a
step back, decided to kill Gonimo, thought a lot, talked with my team members
and finally I became really happy. Happier than I had been in quite some time
and I took my decision back. It is hard to describe, but I am definitely became a
smarter person. Now I am solving real problems, instead of just chasing the
"perfect" architecture, which actually can't be that perfect if it wasn't built
incrementally solving real day to day problems.
Last but not least, my team finally stepped up. They are really supportive
and we work together as a team, far better than it ever has been. We will
get the Android app out there soon, with a whole bunch of improvements coming
next.
In the last sprint we solved nearly all remaining problems of the Android app
and I got to improve the architecture incrementally in a very significant way.
;-)
Lessons learned
If you can't really estimate a tasks complexity it is not allowed to go into a sprint
Instead you should do the necessary research, to get an idea. So sprint planning
is no longer looking at user stories, a little discussion and then putting them
in. If user stories implementation is not obvious, you have to look at the code,
do Internet research - get an idea. If that research takes too long, make it a
user story on it's own.
Importance of planning and evaluation
Before you enter the working tunnel, you should make sure you are digging
into the right direction. That's why planning is that important. If you have
a good idea, talk with others about it. If they agree it is a good idea and
solves actual problems, think about the complexity of the change and how you
can break it up. Is it possible to gradualy implement it, in many small
steps? If not, try it out on a very small example project, see whether it
can in fact pull it's weight.
If you can't explain what you are doing to your colleagues - don't do it.
If you can't explain it, how are you going to implement it?
Well, from my own experience I can say: It works! You can implement stuff you
can't explain or even understand yourself. That's what I did for almost two
months. But it is ridiculously painful and you are going to make very small
progress. You will be much faster, if you take the time, to discuss your ideas
with colleagues, try to make it smaller and implement parts of it on a really
small scale.
Document your code well and immediately
If you explain your code in comments, you are force to think about it.
Especially if you try to do it well. How is this datatype supposed to be used,
what are requirements, how is it supposed to interact with other entities. Who
is the caller of this function? This is especially important for architecture
crucial data types and functions. When designing the new protocol, I constantly
documented it and realized my own faulty reasoning immediately. Writing
documentation is almost as effective as explaining it to a co-worker, probably
because good documentation does exactly that.
A side note: I threw quite a lot of documentation away in this progress, because
the protocol evolved further. This makes it tempting to delay documentation
until you are confident the API is somewhat stable, but the very writing of this
documentation will help you to reach this stability faster, so I no longer
consider it wasted work at all. Alternatively, explain your stuff to colleagues!
Architecture
As mentioned before, I have a really nice new architecture for the frontend,
which I am building incrementally in small steps. I think, I will have a blog post
about it on it's own in the future.
Android status
Most bugs and issues are fixed already. What's still missing:
- Camera selection is still broken. For some reason it is not possible to pick
the back camera, you always get the front.
- On my phone, the app looses connectivity after a while after the display went
dark. So far I was not able to reproduce that issue on any other phone.
- Nice to have: Android back arrow button support. Currently if you press the
Android '<' Button you will leave Gonimo, instead of getting to the previous
screen.
The next sprint will mostly be about organizational stuff though: Getting a
Google Play developer account and stuff like that.
Feedback
If you like Gonimo or don't like it for particular reason, please consider
filling out our feedback form, it is just a
single page with a handful of questions. Getting actual feedback is good for
motivation, which in turn will result in Gonimo getting better. ;-)