Once upon a time there was the Greenfield Project

We’ve all heard of the beautiful almost mythic greenfield project. You get to have fun, experiment with new technologies and new ideas and challenge all the approaches and techniques you've used before.

It shall be the New Dawn. It is worth remembering that the new dawn fades.

The truth is... All projects start like this and become old projects, whether you or your company started them. Typically you will be assigned a project and if you are lucky and unlucky it will be from another company... and often you will be told it as a small aspect 

We’ve picked up a project from another agency.

Umbraco is still relatively a niche market... Calm down I believe (#notacult) and it's bound to happen.

Here is where dragons slumber

BE CAREFUL, here is a company that has chosen to do some work and for a myriad of reasons has left the previous company (possibly even another Gold Partner) and are now asking you to help them redevelop and fix what exists.

Here are some simple things for you as a developer to remember and apply to your project, they may seem obvious but if your are conscientious and apply them particularly the first one you will have a much better experience.

Understanding the money and applying empathy

There is a saying in Hollywood (and other global film industry hubs) that when people start a film, they never aim to make a bad film.

Well the same can be applied and said to any development project. However if you take a somewhat cynical look at development you will learn why understanding and money go together.

So lets go back to the start.

Why do we build web sites

It's ninety percent of the time related to 
MONEY

• Paypal - Transfer of money to make money
• airBnB - Property sharing to make money

A Brochure ware web site is a virtual catalogue of services to get work and be paid for it.
Charity web sites are about telling you about them and to help you donate your money.

There are exceptions (Wikipedia needs money but is not run for any profit)

The client has identified a need of some kind or has been sold on something...

In most cases this boils down to Money

• Do this new thing and you can make “more” (Digital Transformation)
• Optimise your shopfront to get more eyeballs
• You can increase your sales
• You can employ your resources better (another version of digital transformation)

They will also understand that money must be spent, and money will be spent. Because there is trust.

But somewhere along the way this has got lost and costs have escalated and fingers have been pointed and inevitably someone has said ...

I’m sure we could give it a go and do it better than your current developer

You as a developer now have a burden. You now represent ALL developers, and you have to be better than the previous team who did all the previous work, and the client who has already been through this needs to be pleased quicker and more efficiently. How do you do this.

YOU NEED TO ENGAGE THE CLIENT

But I’m a developer, isn’t this a job for the project managers and business owners?

Some will say that’s not what I get paid to do and that could be said to be true. Let me frame this a better way.

How would you like to make your job easier?

I have often found that I have sometimes accidentally saved myself weeks of frustration, because I have sat and been listening to the client and realised what they are asking for isn't actually what is in the specification. It is rare that your client is technical and the art of the project manager or Sales person is not in selling but turning that sales into actionable content, and this means things like interpretation. 

When you are starting a new section talk to people and asking the client "Where's your head at? "

There are three key elements

• Listening (active listening and showing actual response to the content)
• Sympathy (agreeing in a way that put you on the same side as your client)
• Response (this may be a tut tut to an impassioned defence but the right words and the right time will help, and this could mean defending the other company by saying what they have done is good but...)

The benefits of this can be:

• More work (long term)
• More sympathy in return when progress is slow on a piece of work
• More leeway

and if you are really lucky

• Saves you money
• Saves you time 
• Saves you frustration

I have seen people mistaking a site re-skin for a site rebuild, these are things that can easily happen and its also our job to make sure unnecessary work isn't done.

Not My First Rodeo

The client has done a lot of what you are doing before, so remember that.

Be Prepared 

It's cliché but the reason it's cliché is because it's important. Take your time and do the job well.

For some people diving in to code is the meat and drink and it's part of their process, but I genuinely beg you...

DON’T DIVE INTO CODE STRAIGHT AWAY

It's easy to dive in to code and spin up the project and start looking around, but by doing that you are very likely to miss something.

Your first job should be to ask questions about the project, and there are a lot of questions 

• What is the expectation for the project
  • Is it get it working functionally ?
  • New Functionality
  • Speed
  • Other metrics
• What do I get given?
  • Can I talk to the previous developers:
    • Find names companies and individuals.
  • Where is the documentation (this may be your most important question). If you don’t have any handover documentation
    • ask is there a Trello/JIRA board that shows the history so you can understand the objectives
    • Ask what is in the documentation :
      • Instructions on how to install and run the web site
      • Specifications for the web site/app.
    • Do you have all the access credentials for third party services, ownership of domains?
    • Do you have all the files and the right files? Or ideally access to a Github account and the ability to look at all the branches and history. Are the files uncompiled?

Essentially do the research and make sure you have everything they pros work in progress and missed for you to be able to get.

Once you start spinning up the project you will likely get a new set of problems, especially if there is no documentation or commenting.

However those will be specific to the project:

• Why didn't they do this
• Where is plugin X 
• Why is that code commented 
• Oh it's work in progress 

or my favourite

• I'm not sure I understand what they are trying to do here.

Know your tools

Most of you will know these tool sets and how to use them but the more time you spend learning and using the tools the better you will get and you will unlock some juicy secrets.

Visual Studio or VS Code:

Setting up the site to run through visual studio may seem an obvious thing to say but learn to use it, take the online courses some are dull but every so often there is a nugget of information that will change the way you use it:

What plugins have you got that will help you? Style Cop or some other clean code plugin.

You have to loving debug breakpoints and stepping through code.

It may be old school but a table of outcomes can still be useful testing complicated functionality.

Grunt Gulp LESS or SASS

Know your frontend, you may be stuck with older versions of these which may limit what you can do... Look to upgrade if possible.

SQL Server Query Analyser

Learn how and where to analyse queries to optimise them... again it's obvious, but you may not have fully optimised code, you don’t know who wrote it.

It will help find bottle necks and you can then optimise those so you get extra speed for relatively little effort

ReSharper & Dot Net Peek

These are there to help you piece through code faster, there may be other more efficient ways and the latest versions of ReSharper are a little bit clunky but they will help you find things in some cases faster.

Looking at the Code

Lots of people analyse things slightly differently but here are some good areas to start and get an understanding.

I think one of the best places to start understanding is in the engine room of:

the config files
These will tell you whether or cloud services are being used, other plugins.

It may also tell you about databases and database connection strings.

https://our.umbraco.com/documentation/reference/config/

Where is the test service... which leads to is this the code for the latest live release or is it a development branch etc.

How is the code organised:

Is it in well named and obvious folders, if it is it means things will have a logical progression and you aren't going to spend half your time initially finding the right file to edit.

Thanks to Matt Brailsford for this

Look at functional snippets to see how things are named and whether or not they make sense.

public static int FindPositionOfCharacter ((char chr, string str, int beginPos, int endPos){

int pos;

for (pos = beginPos; pos <= endPos; pos++) {

if (str[pos] != chr) { break; }

}

return pos - beginPos;

}

Ask yourself does the function do what it says (In the name, I think this is a bit abstract) are the variables named well and describe themselves (they do) and if they do there is a chance you'll be able to dig into the code with some ease.

Look at helpers

See if they are grouped by types of functions and how are they named.

Look for the patterns

As time goes on the consolidation of code sometimes becomes a nice to do and will be left for others. 

By consolidating code and functions you will make things clearer for those coming after you. 

You will also start to see patterns of how people work and there may be inefficiencies in these approaches, whether it's reuse of a database connection, or a connection isn't being closed.

Commenting Code

Everyone has different views on comments and what is a good comment, and whether your code should even have comments.

I fall into the if it's complicated comment it, this means you have something to refer to in the future and future you will thank you. It also means that anyone else tasked with picking up your code will thank you.

However I find if I am exploring code, it's a good practice to comment code and reorganise it in to logical groupings

• Related functions (all image related ones)
• Complicated functions (Step by step analysis of complicated code)

I occasionally use a technique some times called scream driven development or if in doubt take it out

• Remove code and see what is broken (tools like resharper and others will help you see what functions are actually references) and who screams about it.

Look for large blocks of code that have been commented

These will often be functions that might not be finished and may help you see what work needs to be done, and those will also tell you about how they have worked and understand what needs to be done going forward.

These blocks of code are commented for a number of reasons

• They don't work
• They are finished and don't work
• They are finished but have not got to the stage of the project and causes build errors

Making the client your friend

As a whole you, your team and the entire development should be in contact and showing that more is happening. Now this doesn’t mean bending over backwards unnecessarily. It's about getting the Client on to the same page so when you have issues they will be on your side and will trust you to make the right call.

Happy Developing and Merry Christmas things... Oh and stay safe!

 

Hello My Name is Ravi

I’m an Umbraco web developer, Umbraco community MVP (4x) & you may recognise me from running the London Umbraco meetup, or as the person who was dunked fully clothed into a hot tub, worn a giraffe suit and been part of a breadcrumb code challenge where I was electrocuted. When I am not doing my day job, I can normally be found around East London looking for people to go to pubs with and eat lovely food with.

Lockdown is hard... Attack Hugs to the lot of you