I’ve been working in the web development industry for quite some time, I’m old enough to have been referred to as a ‘webmaster’. I’ve used PHP 3. I have some gray hair, which I’m sure is directly related to using PHP 3.
I joined bleech at the beginning of this year and was introduced to a new way of thinking about web development and one of two possible things happened:
Either I instantly got significantly smarter and better at my job, or this new way of thinking makes my job significantly easier.
So, what changed?
I switched my entire mindset to focus on components. But not just in terms of development, in terms of the entire journey of a web project. Focusing on components from the initial discussions with a client, all the way through to support and maintenance.
And how much easier it is has blown my mind. A higher state of ‘componentness’, if you will.
What is a Component?
This seems like a pretty big claim, so let me talk you through the life cycle of a project at bleech and explain how this thought process benefits you at each point in the project life cycle.
However, first I need to explain what a component is. In our concept it is simple. A component is a self-contained ‘bit of a website’. Let’s take the homepage of this website as a quick example.
The site can be easily broken down into a number of components. For example the hero and the navigation.
These are both components, it’s that simple.
The Component Project Lifecycle
Now that we understand the concept of a component, let’s talk about how we deal with a project here at bleech. We’ll run through a typical project, from initial client meeting through to support and maintenance.
The Initial Contact
The core of what we do is website development. When a client comes to us they will normally have either a wireframe, or a full design concept fleshed out. They will, at worst, have a visual representation of the website that they would like us to build. At this point we would immediately start talking about the website in components, subtly introducing the concept to aid conversation.
Straight away everyone is on the same page during the discussion. As we are all talking about the HeroPage component there is no confusion. The great thing about this is that the name of these components will flow through the project. The HeroPage component is the HeroPage component until the end of the project. When someone mentions the HeroPage component, everyone knows what they're talking about.
Before I started thinking about everything in components it would not be unknown for me to write 40/50 page epic project proposals, significantly longer than any college dissertation I ever wrote.
Other than a few pages of default copy about how we run a project my offers now just consist of a list of components and a cost next to them.
This format has some major benefits:
- Quick: Offers now take me hours, rather than weeks.
- Simple: Clients can very quickly identify what is costing what because each item in the list directly relates to concepts that we've discussed and they can visualize.
- Flexible: As each component is self-contained, the client has a simple shopping list that they can select things from and check each item against its cost and benefit. The components should have no impact on each other so this has no impact technical on the project.
The offer was so simple and easy to understand we have sign-off. We then move into planning the project. As each component has been estimated and has a fairly limited scope it’s then very simple to plan out.
Components can be assigned to developers, and the developer has a clear understanding of the expected timescales. They can also get a really clear understanding of what the components they’re expected to deliver as the scope is contained. Even the most inexperienced developer can comprehend the specification for their components.
This means we don’t have to use a complicated project management system, simply a tool that lists the components, their expected timescales and delivery date and the responsible developer.
I paint a rosy picture above. Clients happy to pay, developers understanding everything, projects going smoothly. However, we still have the same main problem that every other technical agency has.
Client and developers speak two entirely different languages.
Clients speak business, and developers speak technology. The best clients and developers speak both - but for for both it will always be their second language. I’ve spent years joking that I’m one of the best business <-> technology translators around. However, with components, my job as a translator is made a million times easier.
The core concept of a component is simple, but not all components are made equal. Some can end up being significantly more complicated than others. To make sure we deliver these as expected, we have to have a conversation. Conversation is the core of software development and getting them right is critical. This is made so much easier when everything is talking about one component.
The component becomes the common language and the focus of the conversation, leading to less distraction and less chance of miscommunication.
Agency web projects always have a long tail. Regardless of how many different processes, methodologies, and fail safes you put in place to minimize this a website is a complex piece of software and you’re going to have a process of amends and bug fixing before client signs off the final project.
If someone tells you this is not the case and they’ve eliminated the long tail of a web project then they are either lying or have discovered a way to produce software of 100% quality that 100% fits the client's initial concept.
The length of your project tail is what defines a successful agency. The shorter you keep your tail the more profitable you will be.
I’m sure you’ll have worked out by now that I’m going to tell you that components help this as well.
Well, they do.
Firstly developing as components has a number of major technical benefits that allow you to keep code quality code high and crap code contained. These concepts significantly improve your overall code quality.
But the major benefit of this component approach is that each component is a small part of the project that the client can sign off. All parties can easily agree when a component is completed and billable, even if the entire project might need some more attention. Either at this point, the client will be happy to be billed for completed work, or the developers focus their efforts on the components that are still to be agreed, completing the project with a specific focus, reducing confusion and stress.
Everyone is happy and the project is delivered, everyone has been paid. High fives all round! Now what? Well, how awesome would it be to tell your client that next time their project will be cheaper and easier?
Components have the major benefit of being reusable. The knowledge, conversation and code included in the project can be used in the next project. So the next project you do with the similar set of components will run even more smoothly!
Wow, Components are Awesome! But How??
Yes, it sounds awesome, doesn’t it? Happy clients, well-built projects, happy developers. I’m aware it sounds a little too good to be true, and we still have challenges. However, this concept and approach has completely changed the way I think about web projects, for the better.
Want to get on board? What next?
Take a look at our Flynt framework which is the toolset that we use to deliver most of our projects. A great place to start is the starter theme.
You will also find below a video of a screencast that introduces the same concepts with a quick introduction to the Flynt concept.