InsightaaS: Ars Technica is one of the web’s best-respected sources for technical insight. Founded in 1998 as a publication for “alpha geeks”, the site is a source of technology news, analysis of scientific advancements, gadget reviews, and related features. As today’s feature illustrates, Ars also acts as an important exchange point of peer insight. “Should you go forward with a project if the code isn’t clean?” is one in a weekly series of Q&A threads from online expert/peer community Stack Exchange. In it, a young web developer describes a project in which he evolves code to meet a project’s requirements, only to reach a point where “my code is not clean at all, just spaghetti code, and it’s a real pain to fix a bug. All the logic is in the controllers and there is little object-oriented design. I’m having this persistent thought that I have to rewrite the whole project. However, I can’t do it. They keep asking when is it going to be all done. I cannot imagine this code deployed on a server. Plus I still know nothing about code efficiency and the web application’s performance…”
The Stack Exchange community response is pretty clear: ship! One expert states that “You have stumbled on the Achilles heel of most CS educations: they teach you the tools and techniques, but not the trade. Building software is a craft, one which you only acquire through years of practice.” He goes on to say “show the business owner the software, and they feel it’s ready to ship, then ship. If it’s not to that point, but close, finish it. The only software that matters is that which is actually used,” and highlights lessons learned from the experience, providing some guidance for next steps as well.
I’m a beginner Web developer (one year of experience). A couple of weeks after graduating, I got offered a job to build a web application for a company whose owner is not much of a tech guy. He recruited me to avoid theft of his idea, the high cost of development charged by a service company, and to have someone young he can trust onboard to maintain the project for the long run (I came to these conclusions by myself long after being hired).
Cocky as I was back then, with a diploma in computer science, I accepted the offer thinking I can build anything. I was calling the shots. After some research I settled on PHP, and started with plain PHP, no objects, just ugly procedural code. Two months later, everything was getting messy, and it was hard to make any progress. The web application is huge. So I decided to check out an MVC framework that would make my life easier. That’s where I stumbled upon the cool kid in the PHP community: Laravel. I loved it, it was easy to learn, and I started coding right away. My code looked cleaner, more organized. It looked very good.
But again the web application was huge. The company was pressuring me to deliver the first version, which they wanted to deploy, obviously, and start seeking customers.
Because Laravel was fun to work with, it made me remember why I chose this industry in the first place–something I forgot while stuck in the education system.
So I started working on small projects at night, reading about methodologies and best practice. I revisited OOP, moved on to object-oriented design and analysis, and read Uncle Bob’s book Clean Code.
This helped me realize that I really knew nothing. I did not know how to build software the right way. But at this point it was too late, and now I’m almost done…
