Andy Crouch - Code, Technology & Obfuscation ...

Questions I Get Asked This Time Of Year

Oriental Resturant Table

Photo: Unsplash

It comes to this time of year and I find myself out and about more at various functions and parties. As someone that doesn’t drink very much and who is a very strict vegetarian, I get asked a common set of questions. I thought that this year I would write down the answers and direct people here (at least when they are sober).

No, I hardly drink at all. Yes, I know that is hard to appreciate for some people. No, it’s not because of medical reasons or addiction, it’s by choice. When my wife was pregnant I cut out smoking and drinking as an act of support. I found I missed neither but I did enjoy the feeling of a clear head and improved cognitive functions. In all truth, I just didn’t miss it at all. So I never started drinking again. No, I do not miss it. No, it doesn’t mean I am boring. Yes, I occasionally do have a drink when I fell like I want one. No, I haven’t been drunk for over 12 years and that’s the way I like it. I appreciate that some people struggle with this choice but that’s their problem and not mine. (Oh and yes my wife does drink but not to excess and neither of us started smoking again.)

Being a veggie is a more fundamental life choice and I have not eaten animal-based products for over 20 years. This surprises a lot of people given my rounder appearance! It is even more of an issue for some people than not drinking.

I had never really enjoyed meat and had slowly reduced my consumption during my teens by choice. As a child, I started to suffer from migraines that would cripple my head and eyes. I also suffered from some stomach issues as I reached my late teens. On researching them they could have been caused by an intolerance to meat. At this point, I was only eating it occasionally and so cut it out altogether. Instantly my stomach issues vanished and within 6 months my migraines reduced significantly.

“Oh, what do you eat”, “Do you have to live on Tofu”, “You don’t look like a veggie” and “eating must be really boring” are all commonly said to me. These are closely followed by “I can’t live without meat”, “Don’t you regret it when you smell a bacon sandwich” and “I bet I could tempt you to eat meat again”.

I eat a perfectly balanced diet of salad, veg, Tofu and various vegan-friendly foods. I actually like it. I have never, ever, missed eating a bacon sandwich although the smell of a Donner Kebab still makes my nostrils twitch (that could be more to do with the chilli sauce). Please don’t buy one though as I will not be tempted for anything. I like the smell of certain, scented candles, I don’t want to eat one.

If you are lucky enough to go out for a meal with me or to cook for me I am actually really easy. I do not impose my choices on anyone else. I will eat dairy (cheese mainly) based dishes when out to ease the situation and I am happy with whatever you serve. If we are out as long as there is a burger or something meat-free I am happy.

In much the same way I wouldn’t comment on your chosen religion then there isn’t really much you need to say to me about what I eat.

So there you go. I am a non-drinking veggie with good reasons and who you cannot turn with a Big Mac.

I’m fine with it and so should you be.

C# Extension Methods

Glasses In Front Of Screens

Photo: Kevin Ku - Unsplash

Code is all about readability but in itself is not very readable. One of the common statements you learn about structuring your code is to make it flow like prose. That is improved by clean naming and logical structuring and following clean code. But, languages get in the way of this by making you use operators such as !=. Ironic really.

.Net introduced Extension methods early in the history of the framework. The documents state that:

“Extension methods enable you to “add” methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type. “

You can read the full documentation here.

Extension methods are a special type of static method but you invoke them as an instance method. The following is an example of how to wrap up the IsNullEmptyOrWhiteSpace(string) String object method as an extension

    public static bool IsNullEmptyOrWhiteSpace(this String s)
    {
        return string.IsNullOrWhiteSpace(s);
    }

    var testString = "This Is A Test String";
    testString.IsNullEmptyOrWhiteSpace();  // false

The method has to be defined static wihtin a class that is public. It must also take a parameter matching the type it is extending as the first parameter, prefixed with the this modifier. Beyond these requirements, you can do what you want with extension methods.

One of the things that I like to do is negate methods so that you can lose the ugly ! Operator. In the case above I have a matching method defined as

    public static bool IsNotNullEmptyOrWhiteSpace(this String s)
    {
        return !string.IsNullOrWhiteSpace(s);
    }

    var testString = "This Is A Test String";
    testString.IsNotNullEmptyOrWhiteSpace();  // true

I find that this helps with readability and that as a project goes on you find lots of uses for Extension methods. I find you are able to actually define a DSL specific to your project which can be quite powerful. The thing I do not recommend is building business logic into your Extensions. They should be simple, type related methods that add value or improve readability.

Taking this a stage further, I have planned a library of common extensions designed to improve readability. I know that I prefer

    public static bool IsNull(this object o)
    {
        return o == null;
    }

And

    public static bool IsNotNull(this object o)
    {
        return o != null;
    }

Which gives us

    var someObject = new Object();
    if(someObject.IsNotNull())
    {
        // some code ...
    }

Instead of

    if(someObject != null)
    {
        // some code ...
    }

Doesn’t that make reading the code a little easier and clearer?

If you’d like to discuss the use of Extension methods or if you have extensions you would like to contribute, message me via twitter or email.

Always Have A Development Process

Man Standing Looking At A Board

Photo: Unsplash

“The battlefield is a scene of constant chaos. The winner will be the one who controls that chaos, both his own and the enemies.” - Napoleon Bonaparte

When you start a company you have one basic aim, to build a product that your customers love which makes you money. There are many theories and methodologies to guide you toward this goal. The fact remains that the pressure is on to deliver features and profit. In the rush to deliver it is sometimes easy for new, inexperienced teams to work in a chaotic manner. If there is one piece of advice I would offer to any small, early-stage team it would be to create a development process.

I have used a slightly adapted development process in each of my three early stage company’s. It has evolved over the last 10 years due to new applications and forms of communications. I will present it here in rough form and you are welcome to discuss it with me on twitter.

The Tools For Supporting The Process

The process use’s two existing items. The Kanban workflow process and Atlassian’s Jira hosted web application.

Kanban is a method for visualizing the flow of work. It aims to balance demand with available capacity and spot bottlenecks. This product can be software, a sandwich or cars which is where Kanban originated at Toyota. The process aims to provide a clear way to visualise and organise where a task is within a defined workflow. The workflow comprises many states such as In Development or Completed. Kanban limits the amount of work in a given state so that bottlenecks can be identified and resolved. There are some good Kanban articles here and here.

Atlassian builds applications that provide various supporting functions for software development teams. Jira is a tool it provides to log and manage the flow of work through a development team. It provides a way to create a project and set up an agile based workflow to support the work of your team. Kanban is one of the workflows that it supports. At the time of writing Jira costs $10 per month for up to 10 users. An advantage of Jira is that it interacts well with other Atlassian software such as Bitbucket.

(I should disclose that I am no way affiliated with Atlassian. There are many project management and issue tracking applications available. I have found Jira to be an excellent tool but that is my opinion and you can build your process using any tool.)

The Process

The aim of the process I use is to provide enough guidance and support without getting in the way. So, I usually start with the following states:

  • Backlog - All items start here. They should get added and prioritised in the backlog until they are ready to be worked on by the developers.
  • Todo - Items in the Todo state are ready to be worked on. That means the requirements and acceptance criteria are confirmed. If given to a developer they can complete the task with little issue.
  • In Progress - Items In Progress are currently being worked on by the development team. Items may be in a testing phase.
  • Done - Items in the Done column are completed, tested and ready for release to Production.

It is really easy for everyone to understand these states. Especially if you are working with less technical business stakeholders. I find that these states work well before launching a product.

The key to getting this working is to visualise the process. Create a simple graphic and display it in the office and communicate it to everyone. Get a screen displaying the Jira workflow board in the office. Integrate Jira with Slack so that as work is moved through the process the whole team can see it.

A sprint is a period of time within which an agreed amount of work is completed. Agree on a sprint length and stick to it. Pre-launch, weekly sprints usually work really well. I have never agreed to sprints that last more than 2 weeks. Whatever you agree, stick to it and communicate it so that people in the business know when to expect things. Stick it on their calendars and mark the end of a sprint with a demo to the business team.

Include business team members in prioritisation and planning of the backlog. I’ve never had a Product Owner when working pre-launch. If you have one then you may find this approach too simplistic.

If you do have a Product/Project manager and once you have gone live things become more complicated. Especially when you have to start fixing and improving features. I tend to extend the number of states in the process as follows:

  • Backlog - All items start here. They should get added and prioritised in the backlog until they are ready to be worked on by the developers.
  • Accepted - This is the development teams Backlog. Items in this state have been reviewed and broken down appropriately and estimated by the development team. Any item in the Accepted state can be pulled into a sprint when capacity becomes available with no outside involvement of the development team.
  • Todo - Items in the Todo state are ready to be worked on. That means the requirements and acceptance criteria are confirmed. If given to a developer they can complete the task with little issue.
  • In Progress - Items In Progress are currently being worked on by the development team. Items may be in a testing phase.
  • In Review - This state allows for code reviews. Everything your team is completing should be reviewed before it is released for testing.
  • In Test - Items in the Test state have been deployed to an environment that the QA team and/or Business can review the feature and test it.
  • Done - Items in the Done column are completed, tested and ready for release to Production.

I can not overstate the importance on the success of your early stage team by having a process. I have gone through many investment discussion at each of the small company’s I have worked. Each time, the fact that we have a documented process in place is flagged as a major positive. Not only will it improve your ability to deliver under pressure but it will only help your growth.

If you’d like to discuss my thoughts on this topic then message me via twitter or email.

Turning 40

American Football Field

Photo: Martin Reisch - Unsplash

Tomorrow I turn 40. To some people, this may be a massive life event to celebrate (or commiserate). For me, it’s nothing more than another day. When people ask how I feel about my life I tend to think of the following quote from The Big Bang Theory.

“Just like everyone else’s. Subject to entropy, decay, and eventual death. Thank you for asking.” - Amy Farrah Fowler

While I am a little indifferent to turning 40 it has made me reflect on a few things. I have never taken advice well and I do not suggest you listen to me. But, I will write the things I have learnt in life so far and you can take from it what you will.

Surround yourself with interesting, brilliant people.

This is not groundbreaking advice. To grow as a person you need to surround yourself with people that will push you out of your comfort zone. Work with people that make you think and make you question everything you do. Find mentors and learn from them, ask them even the stupidest of questions. The moment you feel comfortable in a profession or a job then you need to rethink your career or find a new job.

Don’t stop learning.

This doesn’t refer only to being a programmer (or whatever you do as a day job). This means read. Read a lot. Read books. Read the internet. Take advantage of the vast quantity of online learning resources. Appreciate the opportunities and knowledge it provides but mindful it can make anyone an expert.

(Pause for ironic effect given the title of this post).

Do things that make you happy outside of work.

There is a theory that to be good at whatever you do, you need to be doing it 90% of your waking hours. This is not true. The key to staying focused on achieving is to sometimes walk away and do something else. There is a culture in some company’s to expect 70 hour work weeks. This is not productive. While you may be working for a prestigious company, you will not be doing your best work. Developers do not need to be building side projects out of work hours to prove they are excellent at what they do. Have hobby’s, go on holiday and enjoy time with your family.

Prioritise.

As you get older you become time poor. Learn to prioritise everything. Once you have a family and commitments you will not be able to go to every conference and hackathon. Learning every new language and JavaScript framework becomes pointless. Learn to focus on the important things and create some time to focus on them.

People come and go.

You will make friends throughout life. Social Media has bred the belief that you have to remain friends for life once you have conversed once. This is rubbish and you may outgrow friendships or they may outgrow you. That’s normal and while some take some getting over don’t look back. Don’t treat others badly or in a way in which you wouldn’t want to be treated yourself. Don’t harbour bad feelings and be open and direct with everyone important in your life.

Be your own person.

Finally, people have opinions and views. The only person whose opinion and views you have to focus on are your own. You will disagree with a lot of people but that’s normal. Be respectful and do not force your views on other people. You can try and educate them but they are their own person as well. We are all the result of the millions of conversations, interactions and experiences that have come before this moment. If you don’t feel good about something then don’t do it. If you wouldn’t say something to someones face then do not write it.

Thats it! Now where is the cake?

Single Responsibility Methods

Man Sitting On Clock Rug

Photo: Kevin Ku - Unsplash

The Single Responsibility Principle is a core element of the SOLID Principles. Wikipedia states that the principle stipulates that

“a class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class).”

Most developers agree with this approach and structure their code accordingly. Then they create methods in those classes with words like “And” and “Or” in the name. This is a clear code smell that your method is doing too many things. Why structure our classes following SRP and then tool them with confusing methods?

As an example, I have often seen code like

public class DataFileParser
{
    public List<Entity> DownloadAndParse(string filePath)
    {
        // long code block that validates that the 
        // filepath exists & downloads it
        // and parses it to a list of objects of type Entity
    }
}

Now I am not interested in showing the actual implementation. What I am showing is that it is common to see a method that does more than one thing. In order for the method to complete it needs to do three discrete steps.

public class DataFileParser
{
    public bool FileExists(string filePath)
    {
        // validate that file exists
    }
    
    public File Download(string filePath)
    {
        // download file
    }
    
    public List<Entity> ParseToList(File file)
    {
        // parses it to a list of objects of type Entity
    }
}

As an aside, by refactoring in this method there is a clear violation of SRP at the class level. FileExists and Download methods should clearly be refactored into a separate class.

public class DataFileParser
{
    public List<Entity> ParseToList(File file)
    {
        // parses it to a list of objects of type Entity
    }
}

public class DataFile
{
    readonly File _file;

    public DataFile(string filePath)
    {
        _file = new File(filePath);
    }

    public bool FileExists()
    {
        // validate that code exists
    }
    
    public File Download()
    {
        // download file
    }
}

This simple refactoring results in two classes that now have a single responsibility. Each method has a single responsibility as well. This improves readability and more importantly makes the methods easier to test. It also makes clear the intent of the methods which reduces the ability for it to cause side effects. Side effects from badly designed methods have lost me countless hours over the years. A final reason to structure your methods in this way relates to reuse. By limiting the methods to a single responsibility you will end up increase reuse significantly as you can chain calls up in various ways that you just can’t when they are grouped together as one method.

To end I will include a quote from Robert C Martin on the subject of SRP

“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”

If you’d like to discuss my thoughts on method design then message me via twitter or email.