In this article, we discuss some common issues that plague web development and the best practices to address these issues.
1. Think before you code
Many developers “Code First” before thinking. Solutions that are not planned will typically end up:
- Tightly coupled
- Hard to understand
- Hard to maintain
- With more bugs
- With too much code
As developers, we should THINK about the architecture of what we are trying to make; we don’t start building a house without drawing a plan first. The people who draw these plans actually know what they’re doing. They’re called Architects!
The best thinking tool you can use is a Unit Test (see next point).
2. Write unit tests at the start
“A software system can best be designed if the testing is interlaced with the designing instead of being used after the design” - Excerpt from Report of The Nato Software Engineering Conference (1968)
Many developers think that unit tests can be written at the end. However, what many developers find is that their code is not unit testable. So we can’t just write tests for our code, we have to write code that is testable!
When we gather requirements from a stakeholder, we write down the acceptance criteria. The acceptance criteria is the test. This is Behaviour Driven Development!
How many of us like to spend our time in the debugger?
With Behaviour/Test Driven Development, we will spend less time debugging, and more time coding. The most amazing thing about Behaviour Driven Development is that good architecture is a coincidental by-product of our unit tests. So, unit tests can actually help you write better structured code!
Related to this, there are some developers who believe that unit testing takes too long, and that it eats into valuable development time. This really shows that they haven’t learned how to do unit testing properly and likely do not fully appreciate the value of unit testing.
Automating tests for the behaviour of your application will save time in the long run. It’s like learning to play the piano. It will take you years to become an expert and you will be practising for the rest of your life, but it’s totally worth it, and enjoyable!
Our typical test suite involves NUnit, Moq and Ghost Inspector. For frontend testing, there’s Karma and Jasmine.
3. Performance profile your code!
It’s hard to find developers who actually performance profile their code. For some reason, people tend to think that a slow website can be fixed with an external solution such as Varnish, CloudFront etc. I don’t know who told them this, but please stop! It typically means that you don’t understand your application.
I’ve seen situations where random cache times were used in multiple layers to cover up performance problems. Needless to say, the applications tend to have random instability and unpredictable performance.
So please, run a performance profiler to see where your hotspots are! You may find that you only need to cache a couple of simple services. You should always implement “Intelligent Caching” over “Blanket Caching”.
The performance profiling tool we use is ANTS Performance Profiler, by Redgate.
4. Load test your website
How many users can your website handle and what is the typical server response time? Many developers cannot answer this question, but it’s something that you should be able to tell the client/stakeholder without even blinking.
A website we recently inherited was running so poorly that it could only handle 15 users, with 30 seconds server response time. We load tested the website so we had a baseline to compare to. With a little refactoring and some minimal caching, it was purring along at 7000 users per minute, and sub-200ms.
So, when you’re building a website or improving one, you should know:
- How much traffic will the website have?
- How much traffic do you want it to handle?
- What is an acceptable server response time? Google says 200ms is good!
- What the Google Analytics traffic is like (eg. high traffic pages)?
Our go-to for load testing is loader.io.
5. Keep your stakeholders informed
“There’s nothing clients appreciate more than deception, and being kept in the dark”
- Said no one, ever! But for some reason, many agencies act this way.
I have seen so many agencies who create a functional document, build for 12 weeks, deliver late, then demo something that is not fit for purpose - it does not fit the client’s needs. The client then has to pay even more money because they are already too far down the rabbit hole to back out of the project.
A better approach is to concentrate on completing features that you can demo to the client - and then demo often (and religiously)! This will give you valuable feedback early in the process, whilst also prompting valuable discussions about the functionality. The client will be informed throughout the process and any issues will be identified very early. One great side effect of this is that you will be gaining trust.
Some best practices are:
- Demo weekly / at the end of each sprint
- Be transparent about blockers and issues
- Tell the client about the things that have run slower (or faster) than expected
- Give weekly budget reports
- In some cases our clients even join the project standups
Anthony has worked with .NET since 2007. He is active in the open source community, in particular the Umbraco CMS, and is a regular presenter at conferences and tech meetups. He lives and breathes automation and development processes, and is a proponent of Behaviour/Test Driven Development. Originally from Sydney, Australia, he is now based in London, working at The Cogworks as part of a development team spanning 5 locations and 3 countries.
The Cogworks is a leading UK digital agency, specialising in Umbraco. The company is active in the open source community and regularly releases open source software. They also run developer training events and conferences, of which the most famous are the Umbraco UK Festival and Umbraco Poland Festival.