2016 Feb

Compromise – Balancing Project Needs with Internal Ideals

Every new project is a new opportunity. It’s when you use your past experience and have the chance to build something better than you did some weeks ago. It’s also the time to use what you learned recently, that new approach that can optimise your solution. Or even that framework that everybody is talking about.

Too much too soon

The team is pumped. The blank canvas is ready for some paint. But then the reality start to sink in. You digest the scope of the project, its requirements and specially the deadline. Time for some reevaluation.

I’m personally guilty of overthinking projects when I first lay my eyes on it. My initial reaction is: ‘Good, I can refactor this legacy code here. We could create a component for that and reuse it later. That new tool that just came out could help us here…’.

Baby steps

My approach lately has been of starting small. A new project that requires CSS standards to be in place doesn’t mean that I also have to rebuild the company’s style guide. In a similar way, a JavaScript location widget could start as Google Maps plug and play and later on evolve into a custom solution.

It’s easy to let our engineering side take over a business problem we have to solve. Compromise is hard and requires the engineer to be mature enough to put his/hers personal choices on the side in favour of a collective benefit.

I know. It’s easier said than done!

The Shift

This post is part of the #startYourShift initiative where everyone is invited to write about different topics each month.