When you work on a project with a tight deadline, maintaining the right focus can sometimes be hard, but it’s an essential skill when you are architecturing a website.
To create remarkable work, you need to explore the edges of what’s possible, to create something cool, you can’t just copy a sample site and re-skin it a bit. If you do, all that you will end up with is a platform which is the same as everyone else’s. Part of the process of a new project is learning to push the boundaries, to explore new approaches, to make the site load quicker, or make the content editors lives quicker. You can’t do this if you copy the same solution over and over and say you are adding value to a project; without innovation you are doing your client an injustice. There is a but… what happens if you have a tight deadline? Not shipping on time just because you want to do some cool stuff won’t cut it, a line in the sand must be drawn when it comes to timescales
I’ve seen countless hours of project time wasted where developers have spent hours trying to prove to each other their way is better. In the grand scheme of the project, if the functionality is not significant, if it doesn’t improve the usability of the site, if it doesn’t make some aspect more remarkable, it’s a waste of time.
If the feature is the unique selling point of the site, the thing that will drive traffic, increase revenue or revolutionise the business, then it deserves attention, if, on the other hand, it’s for some back end class or process and the ‘right’ way is very subjective within the team, then either go with the simple solution, or, if it’s already been built use it, don’t delete code just to prove a point, all it does is demotivate teams and increases the risk your project will not to ship on time.
If you have good unit tests and a good test process, don’t worry about silly details like it feels like it could be buggy, it makes no sense. Focus on shipping and creating excellence, if you lose focus you’ll never deliver. As developers we care about making beautiful code and flexible designs.. the business cares about making money, improving brand awareness and increasing traffic.
A part of being an architect means you need to help push the project forward. I can’t count the amount of times nit picking over the insignificant within a team gets more focus than the actual larger archival debate that will make or break a project. Looking at a class can be easy, piecing together how everything fits together is harder so we’ll ignore that bit and leave it to someone else to worry about it… you 🙂
Now don’t get me wrong. My main aim on a project is building high quality, innovative systems that ship on time. I think it’s vital, as an architect, to be passionate about design, have a good eye for detail. The folks who care are the people I’d rather work with. With a good team you’ll produce a lot more over a team who just turns up for a pay check.
On the flip side of the coin it can be tiring working with people who are stubborn. I think everyone can relate to getting an idea rejected or days worth of development scraped down the drain just because it feels bad or some other silly excuse. There might not even be a valid argument why it shouldn’t be done.
Shipping is the goal and your focus should be fixed on that and not some minor detail. Don’t waste days worth of time unit testing some trivial detail when a time-scale looms, do however have lots of tests around the core aspects of the system. It’s the same as dragging the whole team into long meetings where most people don’t get any value out of it. If you find yourself in this situation just remind yourself that if it’s not adding excellence or improving shipping time, move on as quick as possible.