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!