In this article I am going to share with you some of my thoughts about the business aspect of web development, and how that needs to apply to our principles as web developers (or indeed contributors to any project).
As programmers, developers, coders, whatever you want to call us, we solve many problems. In essence our entire job is to help businesses solve problems, we do it with technology in the same way that accountants do it with financial matters. When there are no problems left to solve we try to make things better.
I believe that good web developers know a range of technologies and how to apply them, this may be in the form of technologies or languages, it may be in the form of methodologies or frameworks, or content management systems. I can’t make an educated decision on the nutritional value of a Wispa Duo (my favourite chocolate bar!) and an apple, if I didn’t know the apple existed, or that the Wispa is bad for my waistline. For the record I concede that I am festively plump in February, and that’s fine.
Now, in order to normalise the many ways of skinning a cat, and to create maintainable software – remembering that money is everything – we, developers, have created a bunch of rules. Things like the SOLID principles, MVC architecture, the separation between logic and display, and everything like that. Hell, WordPress is widely adopted because it solved a common problem with easy (blogs and brochure sites), without having to hire a web developer every time.
So we have all the rules and, unless we have a decent reason not to, we should follow them. Absolutely, without a doubt, not questioning it for a minute. Well, maybe a little bit. You need to know the rules exist, and how to apply them, and I’m a strong advocate of all of them in almost all scenarios.
But the reason I’m an advocate of all of these things has nothing to do with whether I like them or not. They do help us build better software, undoubtedly. However, that’s not the point. The point is fast to build, easy to maintain, quality software is good value for money.
The reason I’m an advocate of SOLID, of MVC, of the various issues of PSR and all of those things, is because it makes my life easier, but the more important side effect of this is that it means I can build and maintain software quickly, with high quality, and high maintainability. It means when the business wants to see my output, or modify a requirement, or change something I can do it. It makes me an asset to a business, rather than a burden, a “no” man or a “that’s going to take some time, boss” guy.
This is why I’m an advocate of rapid application development frameworks. Because they allow the rapid development of high quality software. Time is money, so as far as our value to a business goes it’s about producing high quality stuff and doing it quickly. The same goes when we have to maintain it, which is why the rules are good.
This in mind, I don’t mind bending the rules when there’s a decent case for doing it. If the code is clear in it’s function, it is easy to work with and easy to find. I don’t see the issue.
I could be wrong, but I’m yet to meet a Managing Director, Chief Executive Officer or an Accounting Director who cares about PSR-2, PSR-4, MVC, OOP, SOLID or any of the cool stuff we insist we must know. And that’s absolutely fine! It’s not in their remit to know about those things, they’re our job.
It’s our job, and our responsibility, to deliver quality and efficiency. Once we are a few years into our careers we are expensive resources, with decent salaries, expensive equipment and software, usually a fairly high turnaround (most developers move on within 6 – 24 months). So it’s important we hit the ground running, and prove our worth.
I like making my clients and employers happy, with my ability to turn quality products out in record time. It makes my job far safer than ivory towers in legacy code. I don’t mind bending or even breaking the odd rule to achieve this, if another developer can work on, and modify/extend, the software with ease, then I’m happy. The rules are only there to make our life easier, if I’m not making life harder than I personally think any argument against it is moot.
If I’m showing a fast return on investment to the business, and there’s no question whether I’m providing value for money without cutting the quality of my work, then there’s no question as to whether I should be doing it.
Remember guys; we want to build awesome software that changes the world. We want to build quality software that’s easy to maintain and upgrade; but I’m hired by businesses. If I’m not making the business money, or showing a valuable contribution in decent timeframes, I’m not likely to be around much longer. Eventually I’ll be replaced, or the role itself dissolved and the work outsourced to someone who is doing the above.
Time is money, and money is time. Quality is important, but time is equally important. You have to be able to justify the resource poured into you, and you have to justify it by proving your worth and having tangible output