Andy Crouch - Code, Technology & Obfuscation ...

Summer Post Break

Photo: Lrns - Unsplash

After a long first half of 2019, I am going to take most of August off to travel.

For any readers, I appreciate your continued interest in my blog and my ramblings will return at the start of September.

If you would like to contact me then please reach me via twitter or email.

180-Degree Review Experiment - Part 2

Photo: Mimi Thian - Unsplash

Back in June, I published a post about an experiment I was trying with my team. I had asked them to complete the same review document that I complete with each of them every 3 months. I have now had all the responses and have been reviewing their thoughts.

It was an unexpected task for the whole team. I had a couple of people that completely embraced it and provided great feedback. Some of the team didn’t want to partake but I encourage them to. Some were afraid to leave anything negative. The interesting result was that engagement had nothing to do with seniority.

So what was the feedback? Here goes:

  • The team feel I generally manage them well. More than one of the team felt that I had their backs and would fairly manage issues and expectations.
  • The team is too agile. By this, I mean the true sense of the word and not concerning workflows. As a small team that is reacting to a business that is growing 100% year on year, priorities change. This makes some of the team feel under more pressure than they feel they should be.
  • My group communication style doesn’t work for everyone. This was interesting. In the past I have tried different approaches, meeting schedules and mediums. I have not succeeded in finding a good solution here.
  • My involvement in the wider business is seen as a distraction. I directly manage the team and have no team lead. This means that if I am distracted by financial or management tasks I might not be as available to the team as much.
  • They like the honest, opinionated, feedback I give. My approach to guiding team members to solutions goes down well. Certain team members warm to wider discussions about technology and stacks away from .Net. Others find that a distraction and they are not interested.
  • I could be franker. In certain situations, one of the team felt like my delivery could be more frank or direct.
  • My mood can impact that of the team. It was pointed out that when I am frustrated or distracted by non-team-related issues that I can impact the team.

So on the whole, not too much was fed back, some good and some area’s to work on:

  • I am glad they feel I have the teams best interests at heart. Having worked on teams where that hasn’t been the case I know the impact on productivity and morale it can cause. I see my role to enable the team and support them in delivery. This will only support the ongoing growth of the business and it realising it’s long term goals. This doesn’t mean I always side with the team, it means I find the best solution to an issue and communicate why that is the case. So far it looks like I am successful in this.
  • The team are right about the constant priority switching. This is something I have been aware of for some time. This is the natural growing pains of any company but it is having an impact. Our development process is going through a significant review due to new team members joining in September. This is going to be implemented using a tool to make the roadmap and the Product development open to the whole company. I hope that this will enable more honest conversations with the business over priorities. It will also allow them to appreciate the time it takes to deliver a feature.
  • The points made about my mood and the impact of the non-technical focused part of my role were the most noteworthy to me. I am going to carve out specific time in my calendar to address team and core development issues and the rest of my responsibilities. This will allow me to communicate my focus throughout a week better to the team. I am also going to be a lot more mindful of my delivery and interactions when dealing with issues to limit any negativity I might be letting off. I feel I might benefit from some coaching around compartmentalisation and this is something I will look into.

This is the first time that I have asked the team to do this. I will be pushing the process forward. I will be asking them to do it again in 3 months and every three months thereafter. I hope that as they become more used to the process the feedback will come easier for them to give and be more useful to me. While no earth-shattering feedback was received this time around I can see the long term benefit. While it made me feel very uncomfortable waiting for the responses I suggest you try this with your teams and see if you find it beneficial.

If you have any comments around this post then please contact me via twitter or email.

Singleton Patterns

Photo: Jantine Doornbos- Unsplash

Design patterns are a key element of any developers toolkit. Even if you do not realise that you are using them as you start your career, you are. They have two major benefits:

  • They have developed as proven ways to solve common patterns in software engineering. They are not the work of a single developer or company but rather are an evolving set of best practises.
  • They define a common way to imply intent. Developers will understand code that follows or is based on common patterns. Patterns have become a shared language amongst developers.

Patterns are the basis of a solution. Even if you find you have to add to them for your problem they still provide a useful starting point. Since first being defined by the Gang of Four book in 1994 many more patterns have been identified. In parallel, many antipatterns have been developed. These guarantee that a solution is a wrong way to solve a given problem. Some patterns fall into both camps for some developers. For me, the one pattern I never use in an object-oriented program is the Singleton pattern.

A Singleton defines a class which can only have one possible instance created. It defines a constructorless class that controls how it is instigated and accessed. It offers no public, instance-specific state. Instead, it can introduce global state into Object-oriented programme. They are also always defined as static objects.

I have seen Singletons used in many projects and I have always found there to be better ways to solve the problem. I usually refer to them as a code smell. In a recent project, I was looking at a Singleton class was defined to interact with Cloud provider storage. The class defined a common set of methods for uploading and downloading of files. The implementation for each cloud provider was implemented using a pluggable backend set of classes. The provider to consume was set in configuration during application startup. In theory quite a flexible piece of functionality.

The issue with the code in this project was that it had been implemented in a non-thread-safe manner. This meant that the problem I was investigating was easy to find. A slow method that was looping through a list of objects. It was using the Singleton based instance to create a URL to assign to the object for the location of a file. The solution was to revamp the Singleton based class using option 4 on Jon Skeet’s excellent article on the topic. I then moved the foreach loop to a Parralleel.Foreach and reduced the execution time for the method by 83%. I didn’t refactor the Singleton to a better solution as the class was consumed over 400 times throughout the project. I didn’t have the luxury of time.

This leads me to something else that is problematic using Singletons. You can not easily unit test a singleton. It is a static object which means that if you include it in your tests you will not be able to fake or mock it. Hardly ideal for such a core piece of functionality for this program.

A key aim in object-oriented applications is to remove the use of global state. The Singleton pattern provides a mechanism to use global state. Singleton instances also violate the key aims of the SOLID principles. There are many performance issues to be aware of and refactoring Singletons out of an established code base is very hard. Experience has shown that their use, especially in an early-stage project, is not worth the cost later on.

If you have any comments or thoughts around this post then please contact me via twitter or email.

10x Engineers

Photo: Eddy Lackmann - Unsplash

Last weekend saw a thread on twitter blow up in the developer community. What could get such as reaction from a group of intelligent, creative souls? It was the thread below which highlighted that mythical creature, the 10x engineer and how to spot one. This was the original tweet series:

When I read it I didn’t know whether to laugh or feel sorry for the author. I first suspected it was a ploy to gain attention for his fund, Accel.

First up, as proved here there is no such thing as a 10x engineer. The thread linked to above lists 11 points none of which make either a great developer or employee.

  1. They may hate meetings. Most creative people struggle with meetings that add no value. They do see the value in a company or team meetings that set out their projects and address user feedback. Creative people want to be creating and getting validation. There is nothing special about hating meetings. I think it’s known as being “agile”.
  2. They keep irregular hours and work when few people are around. When growing a company that is not 100% technical this is a major drawback. I worked (not managed) on a team where some contract developers worked when they liked. They would go missing for days, worked through the night and blocked progress on the application. No one could contact them. Feedback was rejected, it was a mess. That was on a project. If you are growing a startup you need alignment with the rest of the company to keep up the momentum. Flexible hours is one thing but this kind of employee will slow your team down. They may even become a negative force in your team.
  3. They change their screen background to black and their i, f, and x keys are worn out. Sounds to me like they just installed Arch and copy and paste their code from Stackoverflow. In all seriousness, some developers just work with default settings and some configure their setups. We are all individual and I have a black coding background to prevent eye strain. I am not a 10x engineer!
  4. They know every line of code that has gone into production. There is a couple of reasons this might be. They are the sole developer or they are a control freak. Either way, there is a big me in team situation going on here! It also explains why they can fix bugs so quickly. With that kind of knowledge comes great responsibility.
  5. They are Fullstack engineers. This point doesn’t even make sense. There are a lot of developers that work across the stack out of choice or because they are a sole developer. He then says they rarely do UI work. Well then they are not fullstack, are they?
  6. 10x Engineers can convert thought into code and write it iteratively. That’s what we all do! In my experience developers “sketch out” code in two ways. They use TDD to help guide their design and thoughts or they write a 200 line method to get their idea out and then refactor it and write tests for it. Either way is acceptable. I have a developer who converts requirements into database design first and then it flows into code. Again, that’s fine. The remarks about developing idea’s in 4 to 6 hours fueled by coffee made me laugh. My TA took a problem from discussion to working prototype in 3 hours fueled only by Tea (he is from Yorkshire)
  7. They don’t read the documentation and write code like English. No developer brought up since Google incorporated remembers the documentation for everything. Every developer Googles stuff and hits Stackoverflow. It’s normal especially when working with Reg Ex’s.
  8. They are always learning new languages and frameworks. Any good developer will continue to self learn. Whether that is frameworks or libraries, it is one thing that most developers enjoy the most. They also appreciate that it’s key to staying relevant. They know what to focus on for their role or career and don’t try and learn everything. Knowing when to use new technology and not rewriting the businesses core application ever six months is the real skill.
  9. 10x engineers are poor teachers and interviewers. That is because they are frauds and lack any personal skills. Once a developer knows something they usually happily share it. It’s how StackOverflow works! Being a poor interviewer can be coached and anyone who has never done it before should be taught how to do interviews.
  10. They don’t hack things. I think all real, committed, developers should be insulted by this. None of us hack anything. We all want to deliver good quality code that follows the agreed best practices.
  11. 10x Engineer rarely move companies or job hunt. When they move out it’s because you make their life miserable with process, meetings and other non-value-added activities. I am speechless. This is coming from an apparent VC. These are the very people that bring structure and processes to companies they invest in to add value and support their growth. This makes it sound like businesses should be grateful that the almighty developer has graced them with their presence. This comes across that these apparent wizards can only work on their terms at small companies. They are not team players.

As you can imagine some of the replies where angry. What made me smile was the developers that shared their insecurities and imposter syndrome fueled feelings. That’s the mark of a good developer. Someone open, honest and happy to discuss their skills, what they know and what they want to learn. I have worked with a vast number of developers across my career. No matter what type of business you are, you do not want to hire someone outlined in these Tweets. They do not add the mystical value they are rumoured to and will potentially damage you and your business.

I for one will be on the lookout for the qualities I mention above that I saw being shared in response to this Tweet. Engaged, eager, capable developers that are team players and aren’t perfect. That way we can all grow and learn together.

If you have any comments or thoughts around this post then please contact me via twitter or email.

Encoding Html Strings For SQL Storage

Photo: Daria Nepriakhina - Unsplash

Recently I reviewed some code that contained a problem that I hadn’t considered for a long time. Storing Html strings in a database.

The basic rule is that you should not store unencoded Html in the database for a couple of clear reasons:

  • Security. If the strings stored in the database are going to be inserted to the DOM or a <script> tag then it should be escaped. You should be following the security guidelines (as a minimum) from the OWASP Project. Doing so will help you prevent Cross-Site Scripting (XSS). Not encoding your Html (or XML/JSON) strings facilitates XSS.
  • It will break your pages layouts. Users have a knack for saving data you won’t have had the chance to think about or test. If a user creates a snippet in your database that includes </body> then you will get a broken page when it is rendered.

Most languages and stacks have inbuilt utilities and libraries for preventing XSS. They can handle the act of encoding so you do not have to write your implementation. In C# you can use the HtpUtility classes HtmlEncode and HtmlDecode methods. The sample code below shows how this works.

using System;
using System.Web;

public class Program
{
  public static void Main()
  {
    var htmlString = @"<!DOCTYPE html> <html> <head> <meta charset='UTF-8'> <title>Example HTML Encoding Page</title> </head> <body> <p>This Is An Example File</p></body> </html>";
    Console.WriteLine("Non Encoded\n{0}", htmlString);
  
    var encodedString = HttpUtility.HtmlEncode(htmlString);
    Console.WriteLine("Encoded\n{0}", encodedString);
    
    var decodedString = HttpUtility.HtmlDecode(encodedString);
    Console.WriteLine("Dencoded\n{0}", decodedString);
  }
}

In my projects, I tend to wrap the HttpUtility calls into extension methods. This means that if I have to change or add something to the implementation going forward I have one place to change.

public static class StringExtensions
{
  public static string HtmlEncode(this string s)
  {
    return HttpUtility.HtmlEncode(s);
  }
  
  public static string HtmlDecode(this string s)
  {
    return HttpUtility.HtmlDecode(s);
  }
}

If you have any comments or thoughts around this post then please contact me via twitter or email.