อยู่ระหว่างการจัดทำบทความภาษาไทย
4 นาที

Software that Services

Chakrit

Credit: https://h-o-r-n-g-r-y.tumblr.com/post/104157435351

Everyone understands software. It’s already easy. Just look at all the startups booming like mushrooms. Every other business person thinks they can ride the wave and wake up a billionaire some years down the road. An MVP (minimum viable product) can be done in six to eight weeks. Just hire some street coders to build their self-proclaimed clever idea. Throw together something vaguely resembling a usable interface. After all, you must be an expert by now. Haven’t you been following that guy on Twitter who always tweets sick mockups? You must’ve absorbed some of his wisdom and skills, surely.

From a coder’s perspective, though, Software as a Service is ultimately a business term. That is because the act of making software, in principles, has remained the same however much it has improved. What changed, is the business model. The only real difference for the coder is that we are now programming the browser instead of desktop applications and Javascript is the new standard instruction set.

And therein lies the problem. As engineers, we are attracted to the reliable, maintainable, and the efficient. Nothing else exudes those values like the silent silicon machine. We want to keep our heads down at the vaguely lit screen and our hands flying over the keyboard. Introverts. Nerds. Geeks. Dictating to the ever-obedient slave in front of us. Code is always logical. Everything always has a reason.

But lift our heads up and our customers are eagerly waiting, knowing that you have the fix to their problems. Not so fast. There’re buttons all over the place, and users are nervous that hitting the wrong one will destroy what little they had just accomplished in the past hour. Every question they ever asked is met with a condescending reply as if it was their fault they couldn’t figure it out.

I believe “service” is something we are truly missing, as an industry. Service comes in many, many forms.

It can be delightful. Just like morning coffee. The type that puts a smile on your face after the first sip because the barista had prepared it to absolute perfection to greet you on arrival, without you having to utter a single word.

It can be dependable. Think of the electricity that powers all the things in your house 24 hours a day, 7 days a week, 52 weeks a year. You don’t even need to think one bit about it, not because you don’t want to, but because you don’t need to.

It can be calming. Like that store clerk who promptly apologizes for the defective product and takes it upon himself to replace it as fast as he can while not asking a single question. Calming, reassuring just like him.

Can we translate those to the software equivalent? I believe that is also easy. We tend to put barriers between us and them. Our software, and the messy world of people. But do we actually want to? The hard part, in my humble opinion, is constantly reminding one’s self that the customer is out there, interacting with what we have created.

Don’t we, as creators derive satisfaction from seeing people become more productive because of the tools we’ve built?

Don’t we, as creators derive satisfaction when people rely on our platforms because they stay online through storm after storm?

Don’t we, as creators derive satisfaction when customers continue to recommend us even though we’ve made mistake after mistake because we always promptly fix them, apologize and then overdeliver?

Often times, however, the creation overwhelms the creator. Every software developer worth his salt knows that every line of code has a life of its own. Attempting to achieve perfect control is a fool’s errand.

At the end of the day, what we create will always be external to us. What we can control, however, is ourselves and how we interact with our environment. Our product and code will always grow beyond our ability to comprehend it.

It is simply impossible to empathize with a machine. It is, however, always possible to empathize with our customers.

It has always bothered me that we use the term “Software as a Service” to describe a mode of Software rather than a mode of Service.

Can we, as an industry, change this? Instead of making “Software as a Service” can we instead make “Software that services?”

บทความอื่นๆ

3 นาที

Humans of Omise: Phureewat (A)

6 นาที

Engineering the user experience

6 นาที

Adapting to life at Omise

12 นาที

The power of terminology in codebase

ลงทะเบียนเพื่อรับข่าวสารดีๆ จากโอมิเซะ
ขอบคุณ!

ขอบคุณที่ลงทะเบียนกับโอมิเซะ

เว็ปไซต์นี้มีการใช้คุกกี้เพื่อวิเคราะห์การใช้และปรับการใช้งานให้เหมาะกับท่าน เมื่อกดยอมรับหรือยังคงเข้าชมเว็บไซต์ต่อ เราถือว่าท่านยินยอมในการใช้งานคุกกี้ของเว็บไซต์ อ่านนโยบายความเป็นส่วนตัว