CTLS 2014 Spring Hackathon

In March 2014, I hosted an internal Hackathon event at CT Lien Solutions.  22 technologist participated by forming 9 competitive teams that dedicated two 12 hour days to developing a working software solution to a CT Lien Solutions’ business problem.  Entries were evaluated on technical innovation, technical achievement, and potential value generation.  We had a winning team emerge (Che’ Smith, Chetan Vihite, and Sarah Althoff-Sams), but their winning idea will have to remain a secret on my public blog here.  Sorry guys.  If you happen to work for Wolters Kluwer, you can read more about the event here: internal blog.  Just in summary, I would like to say that the event was a smashing success.

Here are some of my key takeaways:

1) Don’t let worry about Return On Investment deter you from exploring new technologies and how they might apply to your business.

2) If you have time constraints in your daily job that stand in your way of pursuing new technologies, try setting aside a couple days for a Hackathon event.  Think of it as a training event from a time budgeting perspective.

3) A Hackathon is a great tool for improving technical employee engagement, improving development skills, and injecting some innovative technologies into the daily routine long after the official event is over.

4) A Hackathon event should be conducted separately from Innovation Tournaments that are more focused on discovering the right “What” and “Why” to build, and indeed a company’s normal innovation cycle should always be focused primarily on discovering the right “What” and “Why”.  A Hackathon event is more about discovering new “Hows”, and some of those “Hows” might lead to investigating a new “What” and “Why”.

5) If you are in software development, and you are thinking that you would like to do an internal Hackathon event of your own.  Do it!  I cannot over emphasize the positive energy built by one of these events.

Finally, I would like to give a shout out to Paul DeCarlo at Microsoft, Devlin Liles at Improving Enterprises, PluralSight, Telerik, and Xamarin for their participation and support of our event.

 

Posted in Hackathon | Tagged | Leave a comment

Coding Dojo – Week 6

Our 6th coding dojo was a middle of the day event where we went through the Gilded Rose Kata in C#.  These was a great exercise in working with legacy code, and we were able to build our unit tests, make the required change, validate the unit tests all worked, and then started refactoring code to better use object oriented programming principles.

Our main takeaway was that in the real world when given some code written by folks a long time ago with no unit tests and no documented legacy requirements, we would take some time to determine and document some acceptance requirements around the code we are changing, turn those into some acceptance tests, and then use TDD on our specific changes we are introducing.  We know that we can’t document all requirements or create full acceptance test coverage, but even a little coverage would reduce the risk of a change to legacy code.

For our next dojo, we are going to look at doing a kata that requires F#.

My thanks go out to Susheel, Rajesh, and Glynn for their contributions to the dojo today.

Posted in Software Architecture | Tagged , | Leave a comment

Coding Dojo – Week 5

Our 5th coding dojo was a lonely affair, as the normal crew was either sick, at training, or in meetings with offshore teams.  I took the opportunity to go through Mark Seemann’s Outside-In Test-Driven Development training offered on PluralSight (http://pluralsight.com/training/courses/TableOfContents?courseName=outside-in-tdd).

The concept that you must be able to pull source code from TFS and have the system build and run with no extra setup is one I will take to heart.  He showed how to use the Microsoft.aspnet.webapi.selfhost library to do in-process hosting of his web api allowing for unit testing without any external setup/teardown.  He pointed out that if you have problems figuring out where to start with your unit tests, start with an end state assertion and then work backwards.  Finally, I followed his example of creating a walking skeleton, which is an implantation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end.

 

 

 

Posted in Software Architecture | Tagged , | Leave a comment

Coding Dojo – Week 4

For our 4th coding dojo, we spent our time demonstrating various implementations of the Observer pattern as applied to the Tennis Kata problem.  Susheel implemented a version where the players were subjects and the scoreboard was the observer.  We had a spirited discussion around whether or not the scoreboard’s keeping a reference to the players was a violation of the observer pattern, and decided it was not.  Chris implemented two versions where the players were held in a group class which was the subject and the scoreboard was the observer.  One implementation used the Even/Delegate constructs provided by .NET and the other used the IObserver/IObserverable constructs used by the Reactive Extensions (Rx) in .NET.

Now that my eyes have been opened to these Reactive Extensions, I plan to look a little deeper into this topic.  In terms of plans for our next dojo, we will look at the Gilded Rose Kata and creating effective test cases.

My thanks go out to Susheel and his contributions to the dojo today.

Posted in Software Architecture | Tagged , | Leave a comment

Coding Dojo – Week 3

For our 3rd coding dojo, we implemented the Tennis Kata from scratch.  Before doing the kata, I got a chance to show off a JavaScript implementation using dependency injection (okay, so I cheated and I used TypeScript).  For the record, I was impressed with how easy it was to write working TypeScript code and the Visual Studio tooling around TypeScript is great.

Anyhow, our Tennis Kata implementation turned out to be very challenging.  We decided to implement the observer pattern with the players as the subjects and the scoreboard as the observer.  We ended up thrashing on design for the majority of the dojo, which is okay as we took away these bits of wisdom:

1)We should spend more time understanding the patterns we plan to use prior to trying to use them.

2) We should follow a work pattern where we define our interfaces and object relations in concept, then write the interfaces in code and the object relations using unit tests.  Allow the unit tests to bring the design flaws to the surface.  This work pattern should work for our professional lives as well as it works in the dojo setting.

Between now and the next dojo, I will work on the use case where we treat Players in aggregate as a subject for a scoreboard observer (I will also look to leverage the .NET native implementation of the Observer pattern).  Glynn will work on the use case where the Game is the subject for the Scoreboard observer.  Susheel will work on the use case where the Players individually are subjects for the Scoreboard observer.

My thanks go out to Altaf, Susheel, and Glynn for their contributions to making this dojo a success.

Posted in Software Architecture | Tagged , | Leave a comment

Coding Dojo – Week 2

For our 2nd coding dojo, we worked through the JavaScript version of the Tennis Refactoring Kata 2.  For fun, we used the Icenium development environment and platform, and we were able to deploy the solution at the end of 1.5 hours to an iPad.

Our main takeaway was that the refactoring worked because it created code that was self documenting and much easier to ramp up on than what we started with.  Also, we found that it was valuable to keep refactoring threads of the person ahead of you going when it was your turn at the keyboard, refactoring in small increments set us up for better success than large scale refactoring, and it is best to run tests constantly.

As a side note, our reward for meeting so early was a beautiful sunrise behind Houston’s downtown skyline.

My thanks go out to Altaf, Raj, and Susheel for their contributions to making this dojo a success.

Posted in Software Architecture | Tagged , | Leave a comment

Coding Dojo – Week 1

We held our first coding dojo this week and worked through the C# version of the Tennis Refactoring Kata.  We followed the Randori method and the agenda scripted out by Emily Bache in her book, The Coding Dojo Handbook, and it worked really well.  I can definitely recommend her book and Pluralsight course on this topic.

Our main takeaways were regarding the importance of unit testing to conducting refactoring, the power and value of renaming methods and variables with little or no risk, and we picked up some nifty keyboard short cuts from each other.

The session went so well, that we are going to continue meeting weekly working through katas that improve our refactoring skills until we feel comfortable refactoring legacy production code at will.

Many thanks go out to Glynn, Altaf, and Raj for making this first dojo gathering a success.

Posted in Software Architecture | Tagged , | Leave a comment