Mission: Extreme startup

At the London SkillsMatter office, London Software Craftmenship Community organized an Extreme startup exercise.

It was a great opportunity to participate in a training mission.

The exercise aims at re-creating high pressure development environment. Something just right for a real man! This involves no procrastination or only pen and paper exercise, just real programming. During the exercise, each team tries to build a web server that responds correctly to queries issued by the master server.

I thought it would be easy. What could go wrong during such a short exercise? How naive of me. This mission was tough, but it helped me a lot to better realize who I am as a programmer and what I am capable of.

The Extreme Startup was conducted in four parts:

1. Load
The team I was in was pretty decent. Unfortunately, our computers had one of those bad days. During whole first game phase we were setting up Internet connection.
  
2. Aim

The server can work in a testing mode, allowing players to verify their set up and provided scaffold implementations. (btw. It bears huge resemblance to walking skeleton approach.)
We spend this phase... setting Internet connection. How disappointing!

3. Shoot!
This part was fun! We spent it downloading code, setting up environment and then trying to catch up with the rest of a group. We had a strong feeling that we are trying to build product for a market that is fast changing and all competition is far ahead. At some point we even had a killer idea - but we failed to execute it...

4. Look
Extremely short due to time limitations.

Take Aways

1. Mind Your Squad Size
   Three programmers at one computer is too much. It is hard to achieve something when there are constantly at least two ideas in the air.
2. Steady, Steady...
   Every plan must have it's time to be executed. There is no point at trying a new idea, before you learnt from previous one. We had a great idea (at least three to be precise). However, we did not hold on to any of them long enough to learn about our biggest problem - which was that server did not understand any of our responses.
   
3. "And thirdly, the code is more what you'd call "guidelines" than actual rules."
   So called "good practises" are actual guidelines what should be achieved, and they need to be applied for a given situation. E.g. no team during exercise did TDD, as there was no point to do it for throw away code that changed in minutes rather then days. However, acceptance tests proved to be useful as they shortened loop back time and thus gave those teams advantage.

One gun, many enemies

I spent some time, re-investigating Javascript. After few months of intensive TDD and SOLID training I was curious how those principles apply in slightly different environment. Guess what, they do not differ that much... I wanted to write about all this little later, after gathering some experience from battle ahead. However, Watirmelon post, invited me to attack this subject immediately.

I got through available testing frameworks for Javascript and decided on Jasmine. Why? Mainly because its syntax - BDD style which is fashionable this season. Second reason is that it has really cool documentation. Finally, basic set up was painless to me.


Let's look at basics - what I expect from different types of tests and how Jasmine fits into those requirements:

1. Unit Testing

Aims

1. Shoot them one by one
   (structure your code so that it is easier to maintain)
2. Be sure you kill with every shot
   (verify small bits of code to nail down bug issue)
3. Kill them all
   (verify edge cases)
4. Kill them quick
   (provide fast feedback on issues)

Choose gun which is

1. Fast shooting - the faster you shoot, the more enemies you will kill
   (unit tests must be blazing fast)
2. Reliable - your gun is stuck and you are dead
   (when unit tests are brittle you will stop depending on them)
3. Always close
   (unit tests are your gun, so you must be able to run them all locally)

Jasmine works great for all those aims, as it is really fast and it allows you to stub both objects and DOM elements. Keep in mind that Unit Testing is useful only if you either write new code or refactor old one. Do not ever try to write UT for a ready code which you don't intend to refactor. It's like shooting dead. You simply cannot kill them with another bullet.

2. Integration Testing

Aims

1. Beware of the hidden sniper
   (test against external dependencies like files, databases, network services)
   
2. You are part of your squad
   (verify that components of the application work well together)

Choose the right strategy

1. Observe the environment
   (try to use depenedencies as close to real problem as possible e.g. static file, database with test data, test version of a service)
2. Point in the right direction
   (do not try to test your stack top-down, instead concentrate on interfaces and adapters that you could not test in unit tests)

Integration tests will naturally be harder to quickly setup, they might broke due to configuration problems or inaccessible external services. That's why you don't want to have that many of them. Still, you want to know that all your problems are due to your partner changing protocol. Once again nothing stops us from using Jasmine here.

3. Acceptance Testing

Aims

1. Confirm you are fighting the right war
   (show specification to your product owner/manager/client)
2. Keep clean supply routes
   (test the functionality of your up with full set up and all dependencies)
3. Find hidden mines
   (test your application in all environments you deploy your application to)

Tips

1. Speak in their language
   (use tool which allows writing tests in natural language e.g. Cucumber or SpecFlow)
2. Take your time
   (those tests will be slower, so accept that you will not always run them locally)
3. Spend your resources wisely
   (acceptance tests are naturally much more brittle then other types of tests, so try to keep their number reasonably small)

This is where I would not recommend Jasmine, simply because it doesn't fit this job. It's syntax is based on programming language, so it is harder to read by non engineers. Jasmine allows you to execute events and call your code. However, your users will be most likely using a browser to interact with your code, so it is much better to use some tool that also uses browser to test web page.

Conclusion

I find Jasmine extremely well suited for unit and integration testing. I wouldn't use it for acceptance tests as there are quite few better tools for that job.

Post Scriptum (on DOM dependency)

On his blog Alister Scott also complains about integration issue between his server-side code and client-side code. His experience is that changes to ids and classes in mvc application result in not working javascript. The issue is serious and shows one important mistake which is hardcoding dependencies. Ids and class names are configurable details and Javascript code should be agnostic of them. To illustrtate let's look at test case for a very simple code from my pet-project:

    
describe("GameController", function(){
  describe("During Initialize", function() {
    var view;
    var subject;

    beforeEach(function() {    
        setFixtures("<div id="myid"></div>");
        subject = new GameView();

        subject.CreateFabricInDiv("#myid");
    });

    it("creates fabric in div", function(){
        expect($("#myid")).not.toBeEmpty();
    });

    it("holds pointer to canvas", function(){
        expect(subject._canvas).not.toBe(undefined);
    });
}); 

Do you see how "#myid" parameter is passed into method call? We moved configuration detail out from Javascript code. In my opinion it is simplest solution to Alister problem. This will enable keeping ids/classes consistent between code which generates them and Javascript that uses them. It also helps with code re-usability as you can use the same code on two separate pages with differing ids!

Earn the Tab

One day (actually my birthday), three interviews, three quite different agile companies in London. And one head-hunter repeating continuously "Be positive!", "Be enthusiastic!.

This day was fun!

The first company was by far the best! I arrived at place a little bit too early, so I went searching for a coffee. And to my surprise a nice lady gave it to me for free. Next, I went to nearby park, which turned out to be an old cementary. Nothing better soothes your mind then being confronted with reality of death...

The first interview was really well structured. It was conducted in 5 parts:

1. Introduction
2. Writing code in pair
3. Technical interview
4. Cultural interview
5. Conclusion

I enjoyed coding the most. It was my first experience of pairing with somebody who actually practiced pairing. Before I only paired with people who never did it before. It's kind of hard to teach somebody, stuff that you can't do yourself yet. Of course, as it was my interview I had to show off doing everything super correctly with a perfect TDD life-cycle. Although I lacked some skills, the interviewer was quite gentle to me. And above all it happened in a shared space where all engineering staff is working. I could literally feel the good and friendly atmosphere inside.

Technical interview was checking deeply all I dared to put into my CV. Of course I was asked about SOLID development. We discussed what I think about pairing. And fortunately they asked about REST which allowed me to shine at least a little bit (I taught REST to graduate students in my previous job).

Cultural interview was just chat about being open, about self-development and agile process. Piece of cake. I had no experience, but I read enough about agile to know how it should look like. They asked me also if I am able to work with legacy code, what a question, of course I can work with legacy code! How little did I know!

When I was leaving the building I was feeling pretty good. I liked the company, and the company seemed to like me.

When I left head hunter called - "Be enthusiastic, be positive!"

The second interview was a really well structured disaster.

I came in late (couldn't find damn place). Sweating I came into company office, and I was placed in a small room with glass walls. They gave me some form to fill, which basically required me to repeat stuff from my CV.

Then two guys came in dev and a lead. The first thing I had to do was coding exercise on a code base I sent to them before. I failed miserably. I tried to write this code to the best of available architectural patterns. However, it was pretty hard to extend it the way that the task given to me required. I was trying, but it was simply impossible in the short time limit I had.

When I was going through my ordeal dev was concentrated and helpful, however lead guy was checking emails on his phone. He didn't stop doing that even when I finally stopped coding and they asked me some questions.

I left the office as fast as I could. I thought that they would not hire me for sure. And it seemed like working there would be kind of hard.

When I left head-hunter called - "Maybe it was just your impression that it was a disaster? Nevertheless, be enthusiastic, be positive!"

The third interview was more like a quick meeting. CTO said at the begging that he wants to meet me (probably I had non standard motivation letter).

We started with a short chat with CTO, during which he was obviously making lot's of notes. The guy was very calm and friendly, it was actually really fun discussing with him how he perceives agile. Technical part of this was limited to question about SOLID and DI.

Then I was led to dev space and two guys were asked to verify my technical skills. On of them didn't even react to CTO and me coming. The other started to talk to me, but didn't even offer me a seat. I felt a little like they don't want me there. What a pity, CTO was really nice, but he warned me that company is in the process of transformation to more agile approach! It is not that devs were unfriendly, they just didn't care... The guy who gave me exercise was completely unprepared. First he asked me to make a web page prettier in 10 minutes. I still don't get what he was expecting, I spent 8 minutes looking for any useful, free CSS and then in 2 minutes I hooked it into their MVC view. Test passed. Then he tried to test my coding by adding some feature to their code base. I really tried, but to just get required class under test I had to create something like 8 dependencies! I had no idea what they were and how to do that. In the end he changed exercise to writing in tdd 2+2 exercise. LOL. When I asked about a number of interfaces passed to a class, guy had no issue with that... Not good. I was in dare need to learn, not to teach.

After all those interviews I called head-hunter.
- "So where do we meet for a promised beer?"
- "Can you come to the Victoria Station?"
- "Sure I can, for the whole day I was travelling all around London!"
- "Let's meet up there."

To make long story short. All three companies decided to hire me. One of them was proposing to hire me as a full dev, rest wanted me as a junior (as I was applying for a junior role). And guess what, this was the first company. Great birthday present. I earned the tab!

Training Camp

The time has come, I need to change something and I already know what it is. I want to join the best of the best. I want to be at the forefront of development. I want to deliver best quality software. I want to deliver it fast. I want to see that light int the eyes of people when I present them what I do. I want to have fun every day. I want to be agile.

They are also saying that they pay well...

And they train you while you are fighting for them.

And there is time for innovation. Great! Let's go for it!

The only problem is that joining the best of the best requires Me to be the best. But I am not. Actually, I am pretty good. When I shoot code, it usually brings value. The only thing is that it just explodes afterwards... And all this talk about TDD and SOLID, it seems a little bit overrated, isn't it?

This were many things that constantly banged my mind before I made first step - I wrote down CV. Then I literally sent it to every offer in the internet that had a 'agile' keyword inside. I tried banging on the doors of the most popular companies and I responded to vague offers from agencies. I decided not to be picky as long as I could join a real world agile company. Oh, yeah and I thought the best city in Europe for such a task will be London. Not that far from home, but far enough to make me feel I am changing my life.

After countless emails and few phone calls I got my first serious offer. The head hunter arranged phone interview due to distance between me and the company.

Phone interview? No problem. It's just talking about stuff. Right?

Just before the phone call my heart was pounding and I crossed my room like 1000 times there and back again. And it used to be quite big room!

The first part of the interview was a little like a cultural interview. I was asked about the book I read recently (and mentioned in cover letter - The Agile Samurai: How Agile Masters Deliver Great Software). I was asked about my values, and why I wanted to work in the agile environment. It was all pretty obvious and easy. I really wanted to work in the agile company. But then technical questions came. And I thought that I know something about development:

- Do you know what the acronym SRP stands for?
- Not really.
- Then do you know what is single responsibility principle?
- I guess it's that each class in a program should be responsible for one thing only? - Yeah I was not that sure
- Do you know what is dependency inversion?
- It is when you do no want to bind classes to each other, so you use external library to do that. - If you are not aware I didn't seen difference between DI and IOC at this time
- Do you know what Open-Closed principle means?
- Not really.
- Do you know why the 'var' keyword was introduced
- As a syntactic sugar, so that you do not need to write full class name when it is obvious.
- Not exactly...

And it went like this... At the end the voice said: "Thank you do you have any questions for us?". And I did had questions about their agile practices, about continous improvement and so. The heck, I want to get from this call as much as I can about real world agile. After all this talk I felt sad and devasted. I went to the backyard and started to cut wood into pieces.

For some hard to understand reason they still wanted me to come to the face to face interview. YEAH!

I got to do also a programming exercise. It was about writing discount logic for an internet shop. I did my best. I took free time from work and I spent day and night before deadline doing everything by TDD, trying to structure code the best I could. I was pretty proud of the outcome. I had full suite of unit tests, quite extensive set of integration tests and all requirements of the task were written down as the acceptance tests. I learned unit testing library well and used it for all tests types. I had no time to learn IOC library, so I did all injections by hand in constructors. I overcame few automation obstacles which arouse from using only free tools in .NET environment. And it refreshed my git skills. After all I want to best, right? The code was sent. And once again I had time to sleep.

But not for a long...

Head hunter actually saw that my chances are rising after company viewed the code, so he set up another interview for the same day. This other company also had as part of their interview code test done before hand. This time it was building console interpreter of robot moves. I had the experience but, the time was short. I had skipped one night sleeping (just before filght to London) and once again I did my best. I sent half finished code (but with Unit, Integration and Acceptance tests) just 2 hours before my flight departures. I downloaded all information about SOLID code and Object Oriented design I could and I hoped for the best! Just before I got to the airport the head hunter called me saying he made an appointment for yet one more interview. Chances of getting into agile were high! And all I learned on the way was already to my benefit.

After all I could also be agile. And I could do TDD. And I had acceptance tests. I can join the best of the best.