Extending The ThoughtWorks Technology Radar
Thoughts, goals, and updates.
UPDATE: This project is now open source
It’s been awhile since I’ve posted, part of the reason being I traveled to Europe recently and it was fantastic! It was an amazing trip and I loved every second of it, but that being said — I missed programming. Those two weeks were the longest I went without actively working in Computer Science, although a nice break, I am glad to be back working with the stuff I love to do.
With this post I just want to put on paper the adventures and thoughts I’ve had working on a work project in Node.JS, using Hapi.JS framework(the project code will be released in the future). The project itself revolves around the project from ThoughtWorks — The Technology Radar. The radar’s code can be found here. I was given the task by a mentor at work to expand its ability to be dynamic and transparent. Before I get started I’ll lay down some definitions that is used within the Radar and API:
Blip: A blip is the building block of everything else. It is some technology related to a platform, tool, technique, or language and framework. This classification allows for placement within a quadrant of the radar. The blips are then placed into one of four rings: adopt, trial, assess, or hold. Meaning something like “Ember.js” which would land in the Languages & Frameworks quadrant, and could be proposed that it belongs in the “trial” ring.
Publication: This can be seen as a magazine issue, with this tool we wanted to create a process in which we can create publications and store all information revolved around them. The process for creating a publication usually follows these steps: have developers in your IT space propose a technology/technique/framework etc, a meeting is held where developers and stakeholders can discuss and show their level of support for these blips. This process of proposal’s and discussion can usually happen two to three times, from there these meetings contribute to the publishing of a publication which is summation of this discussion process, these blips will be placed on the radar and developers can gauge what the atmosphere in their IT space is around these blips.
Publisher: Publisher’s are the organisation that published a publication. To allow for analysis between different organizations we wanted to keep track of who is publishing which publication.
Item: An item is the summation of all the blips with the same name, blips can share the same name as the same technology can be discussed at different times, or it could be proposed in a different ring of the radar. Items allow us to look at the evolution of a specific blip over time, and also whether we believe a blip is still worth discussing. For example a blip if a blip stays in the “assess” ring for three to four publications, do we really want to spend more time on it in meetings?
I’ve told you what, now lets explain the why:
- Increasing IT engagement
- Reduce risks of getting trapped with vendors by constantly exploring and reviewing the IT space.
- Improve communication around innovation activities
- Learning lessons once (reduce redundant discovery costs)
Personal Goals
As I am still a very fresh software developer, I wanted to make sure that I had some clear goals to gain from this project.
- Be as concise as possible with code without sacrificing readability when coding. I found sometimes I get so excited to see a working feature, near its completion I cut corners. I want to spend time on each line of code making it as concise and readable as possible.
- Focus on learning and understanding over pushing out features.
- Document as much as possible and follow documentation and linting standards for JavaScript.
- Tests! Create and implement tests, in the very least tests should provide code coverage.
- Learn, and use JSON Web Tokens.
- Understand and utilize the HapiJS framework, and it’s request life-cycle.
When the code does go open source, you may ask “Why didn’t you use <insert framework or library here>” and it will most likely be because I wanted to explore the problem without being given the answer immediately through the use of a library.
Meeting the Requirements
The real question with this project is did I manage to make a project that is dynamic and transparent? I believe I am on track to meeting these requirements. For these reasons:
- Using Neo4J graphing database over a simple spreadsheet gives us an intuitive look at how our data is related, it allows us to store users, their comments and support for blips effectively. Also allowing us to relate blips to meetings, and then meetings to publications. This obviously could be solved with a standard SQL database but with the unearthing of Graph Databases into the IT scene I wanted the opportunity to try this technology out in a non-crucial environment. (Also I love graphs, I believe everything can be represented in a graph).
- The application allows to follow a contributor around and see what they are supporting, what they are proposing. Everything that is needed for analysis is found within the system, this creates a very transparent system.
3. Because data is stored nicely in a graph database, we can reuse it for future publications, allowing for faster deliveries of publications, this also allows us to see the evolution of our blips on the Radar.
Features I am Most Proud Of
An Expandable API that interacts with the Neo4J database. When I was first implementing the API I wanted to make sure that if I wanted to change or add endpoints and its interaction with the server I only had to change one file. I did this by creating a “Valid actions” file, which sort of looks like this
This file and along with a builder that uses this file as a rule-set, is the layer between the API and the server, it creates the Cypher Query that is needed for the server to understand the request.
JSON Web Token Authorization was an incredibly fun to research topic. I did utilize the help of a library to augment my HapiJS server to use a JWT authorization strategy. The implementation of the creation of users and properly storing their credentials using a hash function (using Bcrypt) was an incredible learning experience and allowed me to peer into good security practices.
Feature Toggling was something I was a little hesitant to implement, but was pushed by a peer to try it out. I was scared it was going to add complexity to my project that might not be necessary. But I’m really happy that I implemented this feature. I have been using it as a way to switch the project between the corporate version we use at work, to the open source version I plan on releasing in the next couple months. For example I use a feature toggle to toggle between how I want a user to authenticate, where when its off it defaults to finding the correct user hash in the Neo4J database, and when on it uses our in house authentication. Good article on feature toggling is here.
Overall, I feel very good about this project. I have been keeping to my goals and have learned a tremendous amount on how to properly implement and execute an API. There is also so much more for me to improve on, one of the major things that this has unearthed is how little I know about testing in general and how to properly test. Moving forward I’m going to try and focus on implementing more thorough test cases and trying to find better testing strategies. HapiJS is also a pleasant framework to use, so big shout out to those developers. Thank you for producing such a pleasant development experience for me!
I hope to bring this project to open source by the end of the summer, but it still is very much in the alpha phase!
Cheers!
