A question that has popped up during several client and prospect discussions over the past few months is:
What do you mean by scalability?
This is always an interesting conversation, and to say there is a stock answer would be misleading of me. So, to me, scalability and the answer about what it is, is different for different clients.
Listen, Actively
I do think that as developers we have an innate gift for rapidly digesting a client’s situation and mentally developing a solution on the fly. Of course, we elaborate on this later, often too much, but we are a breed of prognosticators and problem solvers.
I always cultivate clients discussions based on their environment. After all, that must the job of any developer, if you can’t empathise with your client’s business and their business’ needs then how the hell you gonna develop software that helps them at all?
A mantra of mine is:
Understand your customer on their terms, do business on yours.
It’s always better to lead someone to a conclusion than to tell them what the answer is. This empowers the other person, it gets them to tell you what the solution is, even though you already know the answer.
Don’t just listen to your clients, but actively listen. This means doing more than just waiting for your client to stop speaking so that you can have your turn.
Clients, and in particular – new clients – are itching to tell you what their problem is and will also give signals about the level of financial commitment that they can make towards solving that problem. When you actively listen, you hear those signals, when you only wait for the gaps in conversation – you don’t.
So you might ask what’s this got to do with scalability? It would be a good question if you didn’t interrupt me and kept reading, see you are not actively listening or reading now 
.
Constraints of Scalability
Software scalability at its lowest level is: The ability to grow at the rate of requirement, or faster.
You could also throw in some suffixes to that statement, such as, “without great upheaval” or “without major rework” and so on..
There will also come a point in the development of some FileMaker Pro applications where the client will outgrow it. This may only happen to one in every one-hundred applications that you develop, but during your career you will be party to this.
Don’t worry about it. In fact, make the client aware of it early on if you feel that there is a good chance that your client may be affected by it. This gives you more credibility, not less, and allows the client to plan and make business decisions around a known set of facts. If you think that hiding this fact might protect you, then you are just kidding yourself, the conversation when the client ultimately realises it will be a very tense conversation and probably the end of your business relationship.
Around four years ago I had a particularly bizarre instance of this, where my client went from literally not even understanding they had a dire need for a custom application, at all – to outgrowing one within 18 months. They then moved onto a more appropriate web-based application which I helped them to develop with another company, and I still do business with that client on a regular basis today.
Apart from hard scale limits, which are just limits of capability if nothing else, there are many other reasons that we need to make software scalable, perhaps because there is no current need or there is no current finances available. You can’t, and shouldn’t, make your customer go from a Hang-glider to a Learjet in one step. You should give them a Biplane to start with, then a range of Fokker’s before giving them something of real potency. This process is scalability.
Quote of the day»
I know it’s difficult to stop yourself giving a client every trick in the book in their first application. This is particularly true of clients that don’t have deep I.T. awareness or knowledge of how databases work, and you are eager to impress all your knowledge in one fell swoop, upon them. This is a mistake.
The Tsunami Effect
Not least because every feature needs explanation and training, you can easily maroon your client and their staff on an island of confusion. You will make them feel that they’re surrounded by a sea-of-change, without a raft to paddle. Don’t forget that the switch to a database is in itself a learning curve, without the added features of your application.
Like a Tsunami, the change can wash over them leaving carnage everywhere. This makes everyone feel demoralised, dejected, and anti “your” application. Note that I call it your application. If you have reached the implementation stage of a new application, and your client still views the application as your application, you have already failed before the first boot-up.
Stop Thinking of Scalability as an Option/Aspect
Scalability should drive the entire development process. To me the whole development process is one of scalability. Through this process your client can see the possibilities, even though they may not need all of them for a number of years. Guiding your client by active listening, letting them tell you the answers will make your client own the application. It will become their application and you will simply be working on their application. A much better scenario.
Changes, modifications and reworks now all become client driven, subtle changes in conversation appear, such as your client asking “how much would it cost to change [item1] to [item2]?” Much better than telling your client that they need [x] and it will cost [y] – there’s inbuilt tension within the statement itself.
Scalability for me is the art of strategic thinking, the ability to see where your client’s business could be in x-Years time. Scalability is not a linear decision, it’s radial. It’s your job as a developer to draw that concept out, mentally and physically, and make judgements from it, those judgements become the scalable factors – and some will never see the light of day.
Of course the other benefit of drawing the scalability map for your client is that you are creating a wish-list for them too. Once they see what is possible, it is not too far a leap to trigger those wish-list items when a certain business event occurs or milestone is reached. And, those smart enough to include their client’s milestones on their scalability map will naturally trigger the enquiry process. “When you reach milestone [X] a module [Y] could handle that, at today’s rate – that would cost [Z].”
Double Dutch Doesn’t Mean You Get Twice As Much
I like to use metaphors a lot, I like to use pictures even more. But, when I can’t use either of those I just make lists. As much as there is a need to make monumental sized reports for pitches and specifications, and sometimes bids, there is also a permanent need for common sense. For me, common sense is just a phrase that means: how to convey logic in the least number of compelling words..
Clarity, it’s a concept that many people never really grasp. In a bid to achieve clarity, they stumble, cough and splutter and keep adding to documents and emails and communications – without ever editing out the crap.
Invariably this leads to communication paralysis, your client hasn’t yet grasped the initial proposal you made, and you’ve now come back with a hefty list of additions – you’ve also just booked them a ticket for that one-way journey to maroon island.
Clarity and scalability go hand-in-hand. You have to achieve clarity to be able to compel and convince your client, use scalability as a way to give your client economy whilst at the same time laying the foundation for future revenue for yourself. Of course, your application has to solve the initial problem, but it doesn’t need to do it to death upon hatching.
Chicken Nuggets – Chicken – Egg
Yes, the order of those is screwed up, but in very basic terms, the order of the day is:
Client lays egg » you rear Chicken » you leave Chicken Nuggets behind with client as a taste of the future.
I told you I like metaphors..
About the Author: Darren Lunn develops custom applications for people desperately in need of custom applications. He also helps them understand the future without the use of a time machine.
No related posts.