As developers, understanding our non-technical partners’ needs is the best way to develop great code, says Ben Greenaway.

Scope and Purpose
Keine Kommentare

It might be a brochure, a tool or a fully-fledged application that you last created with PHP. Whatever it was, chances are that it had a fairly broad spec. You probably extended the requirements again with repurposing and reuse in mind. And if you’ve been following recent trends, added a social media requirement, a mash-up opportunity or exposed a new, public API.

Over the past eight years the growth of application for PHP projects has similarly extended the design vocabulary of our clients. And at the same time, public end-users have equally grown in sophistication and understanding, allowing in turn the development of richer and more deeply engaging experiences across all supported browsers, device clients and APIs. It is a good time to be a web developer.

This story speaks to a simple fact, and it is one you should proudly be telling many times over. Our industry has matured, its tools and techniques now forming University degree programs and being written about far beyond our trade journals. A dozen years of Agile development has done us the world of good, and a new professionalism has bought – perhaps more than anything else – a much needed critical distance and appreciation of our output. Though sometimes it is not so obvious that we benefit from it.

Consider the following situation; an enthusiastic client or disruptive startup employs you to develop their application. They plan to ‘buck the trend’ and do something utterly unique for their field. Having spent the last year refining the plan and raising capital they begin by building a development team that you will lead. It is a brilliant idea and you love it. Your bosses are new to the web and bring an entirely new concept with them from their own industry, but are unfamiliar with our development protocols. The holders of the purse need their risks mitigated and to know that everything will work safely. To satisfy them, you begin to explain how your solution will work, reducing each complex process to simpler, familiar problems. Time spent explaining how things don’t break if built a particular way consumes much of your early research and definition stage and larger project milestones begin to approach all too rapidly. Your enthusiastic team turns their attention to other matters, leaving you to lay down the code and begin commissioning hosts. You start spending that precious purse without having iterated the design even once. And from this point on you’re back-hoofing it.

Eventually, the day does come when your broader appreciation of the project allows you to offer up new features, but they are likely met by your purse-holder’s objections to changing the plan just now, and you are told to include them in the next version.

And the scenario applies just as much for a team lead on existing product as it does for project leads of legacy teams, too. In collaboration with your client or your executive, or even the lead on your current project, try to be spending your time on “how it could work” stories rather than “why it won’t fail” ones. When you do, you are much more likely to develop additional features soon enough to include them and identify smart extensions to create additional value in your products. The vast majority of successful projects began this way, including PHP itself. And conversely, the best way to find out which code you should be writing for yourself is through discovering a purpose for its development that a client currently may have.

When you do next sit down to begin your next creation, remember that our new maturity is best embodied by taking this more understated approach to championing the brilliance of our coding. We need to be generous with our features and the time we will spend on their refinement, and no less outgoing with our design and the communication of it and its goals and potential for our collaborators. Doing so gives our code a shine all the more brilliant from its deeper reflections of our client’s conceptual intent than any trendy torch shone blindly into eyes of startled users can.

We write great code when we have something great to build with it. Economists agree that economic recovery will be most sustainably led online and through our tech sectors. So when working with your new client or on a new project, advantage yourself and the rest of us of the full opportunity it presents. Engage with it’s intension and purpose, not just the tools and technologies you need to build it. When you do you will find the killer-apps and the richer, more engaging experiences which can move us all forward.

Ben Greenaway has been a software developer for 18 years. After pioneering internet narrowcasting in the 90’s and collaborations with Cyberia and Virtual Futures on web installation projects he led development on A/V installation projects for Pixar and Sony Entertainment and web applications for SMEs in Southern California before moving to the San Francisco Bay in 2010 and developing performance solutions for Dyn DNS and e-commerce APIs for Tzolkin TZO. He now lives in South London where he balances time writing and developing with the demands of an ever growing collection of retro home computers.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Benachrichtige mich bei
Inline Feedbacks
View all comments
- Gib Deinen Standort ein -
- or -