Posted by: Daniel Boterhoven on Fri Feb 05
Going from the backbone of enterprise with niche commercial appeal to a global juggernaut that spans every field you can imagine, its demands have changed greatly.
No longer is it the exclusive domain of the tech-savvy and those wealthy enough to leave everything in their hands. Its modern accessibility to even the smallest business is great for both developers and their clients, but requires careful communication and organization. When you go mainstream, you lose the ability to fully dictate the path you travel.
Consequently, the best developers recognize the need to be flexible in numerous ways. Being stubborn and set in your ways is likely to end up damaging your business. But why is this, exactly? Why is flexibility such a key part of the development process? Let’s find out.
Imagine a company contacting a developer with the intention of having them design a mobile app. When asked what their goals are for the app, they simply note that they’ve heard about mobile apps, and they want one. They’re looking for a mobile app like the best ones on the market: something that will impress their customers and win them new business.
Following this, a good developer should stop them and make it abundantly clear that it would need actual specifics about the app before it could develop it: what features it should offer, what style it should use, what platforms it should work on, etc. But even after having all its questions answered, could that developer really trust the provided information?
After all, it isn’t unheard of for a developer to throw out some possible ideas to get the prospective client thinking, only for them to grab the first idea and say “Yes, that’s what we want, 100%” — what happens if that idea gets delivered, only for the client to object to it, having had no idea of what it actually involved?
It’s little use objecting (quite reasonably) that they client is at fault there for committing to something it clearly didn’t understand. The developer will end up taking the blame, losing business, and being slighted to other companies for being “misleading”. The most sensible thing the developer can do is take everything with a pinch of salt, and be ready (while dealing with a troublesome client, at least) to turn on a dime.
Anyone who has ever worked in a position requiring them to liaise with clients on a regular basis will know how capricious managers can be with their resource allocation. One moment a project is the absolute top priority with an unlimited budget, and the next it’s been all but shelved, stripped of anything but the most basic funds and treated as a waste of time.
For a developer, this can lead to a lot of frustration, particularly if it’s using a waterfall project management method. Plan a project in its entirety on good faith, get halfway through the execution, then be told by the client that the budget has vanished. In principle, there should always be a guarantee of payment before even starting, but sometimes it’s necessary to take risks to win over a client big enough to take your business to the next level.
Because of this, it’s much more sensible to take an agile approach and treat the project as modular. Having flexibility in how you handle the project — being able to tweak the order of priority, or discard certain parts entirely — makes it possible to bring even a project with a disrupted budget to a successful end.
Development tools may have come a long way over the years, often making it easier to port software from one language to another, but compatibility has become more of a problem.
A piece of software developed even just ten years ago might have been completely self-contained. You run the software, use it for its intended purpose, and don’t need to hook it into any other systems. But it’s now somewhat rare that a given piece of software won’t need to integrate easily with various types of system, be they suites, apps, or SaaS solutions.
Why does this demand flexible development? Because integration systems and APIs appear (and are updated) at such a rate that you can’t easily anticipate what you’ll need even just a month down the line. You can configure a program to work with a certain CMS today, only for an update in two weeks to break the integration and require alterations to be made.
Look at how the ecommerce world handles things: because there’s so much riding on the steady uptime and functionality of an online store, it’s simply unacceptable for integrations to break on a regular basis, so custom systems are only used by merchants wealthy enough to retain dedicated development teams. Everyone else will prefer standard hosted systems, whether they’re building, commissioning, or outright buying their ecommerce sites.
In some ways, this point draws from each of the three we’ve already looked at. Suppose that a client doesn’t really know what it wants, and doesn’t really know what to do with its resources, but starts a project anyway. While progress is ongoing, some new social channel is released and attracts a lot of buzz — and the client needs it to be integrated.
In fact, they can barely understand why it isn’t already there. Shouldn’t the developer have seen it coming? Surely it was unprofessional not to plan ahead? Once again, explaining that no one could have anticipated that success so far ahead of time might fall on deaf ears. Staying flexible makes it possible to revise the plan and work in something new.
But that’s only the client-facing value: there’s also internal value to be found here. Let’s say that a developer uses a particular project management suite for its work, but a new suite comes along that offers a comparable interface with a greater range of functions. If there’s something to be gained from moving to that suite right away — and there’s sufficient flexibility in the project to make such a move — then what reason is there not to do so?
A high-level software development project can drag on for years. If everything is set out in stone from the beginning, there’s a decent chance that the final result will be deeply unsatisfying to all parties involved. By maintaining a fair degree of flexibility in approach, attitude, and intent, a developer can achieve better results and minimize stress.
Subscribe for updates