Interested in the whole serie?
part 1
part 2
part 3
takeaways
It has been few weeks since I stared my new project. I think I'm ready for a wrap up. Here come things that I have learned/noticed during these few days of coding.

Breaks Work

Whenever I was stuck and took a really long break - like 20-30 minutes - then, as by magic, the solution appeared in my head.

(picture from http://01tutos.com)

I have to admit, that it is not easy to take a break. It is hard to get rid of this thought that "this time, this minute, I will deduce stuff, so let me sit here for another minute". And I sit, and sit, and sit, and figure out nothing. But of course, I realize this too late each time, which is frustrating.

Yellow Duck Eats Breaks Alive

Another way of getting out of being stuck is to explain your problem to someone. I have had this so many times, that while explaining, I haven't even finished the story when suddenly the solution became so obvious to me.
The downside is that you interrupt someone's work. But usually people are glad to help.

Documentation is Like Duck but Does Not Quack

One thing about documentation at this very early stage of the project is, that it is not about others reading it, but about me writing it (and thinking during the process). It is a form of "yellow duck" - but instead of talking to someone you put your thoughts to the paper. It works similarly.

(picture from http://funmozar.com)

From the very beginning I was writing documentation, and it helped me many times to clarify my thoughts. Sketching all kind of diagrams also proved to be very helpful. Few boxes and arrows, and voila! - I can see much clearer now. It was especially useful when I got too deep into coding, so I couldn't see the big picture anymore.

BTW. I have blogged about some nice tools for diagrams etc. - see http://kaczanowscy.pl/tomek/2014-03/4-cool-online-tools

Discuss Things

I have already mentioned that presenting your plan, your design, your architecture and your ideas to a group of your fellow devs is probably the best thing you can do. The earlier, the better. It saved me great amounts of (pointless) coding and frustration.

Still, even with help of other smart people, it is not like the design we selected was perfect. I had to introduce a lot of changes since then. I guess it is normal - the higher you climb, the more you can see.'

Which also means, that you should discuss this stuff more than once.

P.S. Some things are hard to predict, but with good design their impact is limited (e.g. to one layer only).

Start with the CI

I haven't mentioned it, but before I had any code at all, I already had Jenkins job created. This is the first thing to be done when starting a new project.

Also, it is worth checking if you can release your project (in case you live in the world of Maven Release Plugin) to avoid some unexpected errors much later (like credentials issues, lack of tags dir or some cryptic git messages etc.)

ATDD Works

It helped me a lot to start with an E2E test. All the stuff I did to create a walking skeleton, all the configurations, parameterization, the ability to run my app with "one click" - it all paid off.

Also, having a (very simple) goal allowed me to concentrate on the important stuff.

Tests

I have found out, that I often start with the simplest case. One could argue that there is not much value there, but I find it helpful. It is kind of a warm-up for my brain. It helps to build a base for all other tests - you know, you need to create all the mocks, create the SUT etc. So later, when you start testing more challenging scenarios, you have this basic building blocks already prepared.

Tests are addictive, meaning when I start writing them, it is hard for me to stop. This is no good. Few times I went too far with tests, meaning I covered scenarios which were not important at the moment. Somehow limiting my coding only to things required to fulfil the main requirement (as described by some end-to-end test) is hard.

TODOs work

When writing code in order to finish the first spike, I left a lot of TODO comments in the code. Like this:

// TODO validate

I did this when I felt like there is so much more to be done, but it can wait. It allowed me to follow the main path, without being distracted by tiny details. A good thing.

Of course, this requires discipline, so that at some point you come back and clean all such TODOs!

Proof-of-concept failure

Few paragraphs above I praised the discussion I had with my team mates regarding the design etc. Well, this is exactly as I felt at that moment, but... Well, I will confess it to you: not everything worked as planned. In fact, things went south at some point. The code simply got too complicated. From the very beginning I could feel that there is something wrong with the abstraction. But still, I fought. I decided to prepare of PoC and I did it. It was awkward, but it worked. It felt wrong, but still it worked. I proved a concept, I proved this can be done this way.

(picture from http://mastersofmedia.hum.uva.nl/)
Well, stupid me. Later I had a discussion with another guy. This was a turning point. I removed 3/4 of the code, replaced my own (bad) solutions with some ready-to-be-used components and voila! - things got much better since then.

The takeway: talk with the right people.

P.S. The idea of "PoC failure" comes from talk by Jakub Kubryński Confitura 2014 https://www.youtube.com/watch?v=w-I2nd2WP4I&index=12&list=PLVbNBx5Phg3C_... (in polish!)