Some people may even keep things organized and build a few ordinary things. But, the ones who rise above others are those who build things that get people talking positively, which leads to others spreading the word around.
Remember, clients don't buy tests or beautiful code.
Clients don't go around telling their friends about the clean code somebody wrote. But, they do talk about how happy/relieved/excited they are after someone helps them with a problem. Once their pain is taken care of, then they might get to appreciate anything else.
It's said that Steve Jobs wanted the iPhone's internal design to match its external elegance, even though most people might never see their phone inside. Say we hire someone to build our server room. Who would you trust more... the person who creates server rooms like the one on the left or the right?
Though we may never have to see something like this, looking at the server room on the right would calm us even without understanding what each of those cables does, where they come from, or where they go. But, the neatness of the work shows care.
It is the same with code.
Most clients aren't likely going to look at code. But should they decide to take a peek while they brag to their friends about the amazing solution that some company did, it's better that they should find neat code. If they do venture into looking at the code, it's important that the developer is able to quickly go from "this is the code" to "this is the problem it solves for you... which brings us to thoughts about the "dev speak".
Dev Speak
Many years ago I had a great friend who lived in Houston. He was an immigrant from Argentina and made a living painting houses. He worked with a crew consisting of other immigrants. He was their leader and made the most money. Why? Because he was the only one who spoke English. He was able to talk to the customer, understand their needs and concerns, then negotiate.
Why am I thinking of this?
Well, some developers are a lot like the immigrants who can't speak English. They can only speak their own language made up of a lot of technical mumbo jumbo, but cannot talk to the business or understand its leaders' needs and concerns. The alternative is to actively listen to the client and pay attention to details. For example, accountants always say their debit first. "When a payment is recorded, debit bank undeposited funds, credit accounts receivable".
That's how they talk.
When stakeholders walk up to the whiteboard, pay attention to how they draw their vision. Consider it a part of the UX/UI work (In that order. Experience first!) To provide them with a good user experience, the user interface should reflect that vision, that common behavior used when articulating their thoughts:
Accountants like that. They tell others about that. They feel understood. If they'd like to see the "server room", we could start by showing them the automated tests that document their needs and solution.
"But code looks like Greek to me," they may say. Invite them to have a look anyway.
"Oh, I see debit undeposited funds account, credit accounts receivable account!"
After a quick explanation of what a spec or test is and its value, we can show them the code that implements that feature:
"Oh, again, I see the debit and the credit in the middle of those brackets and semi-colons!" I believe that's a good way for clients to:
understand and articulate what we do clearly to others
trust us and be confident that we will have their best interests at heart
To close these thoughts, here is a short story.
A client once told me at the start of a project, "The team doesn't have to worry about the other business owners. Your job is to make me happy." However, I respectfully disagreed. "No, our job is to make your clients happy. If we succeed, we guarantee you'll be happy."
That is a story that gets retold.
Reach out to us if you would like to learn more about our IT development services.
