Table of Contents

Who is Ralf Westphal?

I’ve worked in the software industry since 1986 as the co-founder/CEO of two companies for a total of 12 years and since 1998 as a freelancer.

Getting to the bottom of fundamental questions of software development and working collaboratively is what drives me.

It’s a search for truth. And it’s a fight against illusions, unquestioned beliefs, deep seated habits.

Maybe that’s all an effect of having taken some red pill? I don’t know.

What I know, though, is that I’m on a quest for whatever works better. Finding new (or forgotten) ways to make software development easier, to lessen its pains, that’s what I’m focused on.

And quite often the starting point for all this is my own experience: I imagine, that what’s burdening me must be burdening others, too. Hence by making things better for myself, I think, I can improve things for others, too.

So, when I finally chose the path of a freelancer it seemed, that a fitting description for what I’m doing is “One Man Think Tank“: Every day I’m making it my job to think hard about stuff other’s don’t have much time to think about. And as I’m thinking about it (and researching what others have done) and uncovering ways to make work (and life) easier, I can also help those who don’t find time for that while being busy running their businesses.

A more detailed description of my life’s journey you can find in my resumé.

Currently I'm living in Bansko/Bulgaria and doing all my business online. It's a cool as well as beautiful place to live.

Working online/remotely is in no means an obstacle, but a boon. It makes meetings of all sorts more flexible, more fine grained, and supports a more a sustainable way of being of service to my clients.

Where I’m coming from

I started out as a software developer infatuated with technology. I loved to try out the latest frameworks and tools. And I applied technologies in the software I developed for my clients. And it all started in 1980 with a TRS 80.

But then somehow that changed. I began to write about technologies instead of building products with it myself.

Then I got interested in the structures into which technologies are embedded. Software architecture became a topic in my articles, talks, and consulting engagements.

And then, moving onto yet another level of software development, I started to think about how software structures could not just be made functional, but long “living”, i.e. be easy to evolve in the face of ever changing requirements. Reading “Clean Code” by Robert C. Martin got me onto that track.

But I’m an eclectic. I don’t want to be glued to any one thinker or approach. I could not help but let my thinking about clean code development evolve. Although I’m still all for getting code clean at the most detailed level, I’m also concerned about the prerequisites for that: designing models of code and analysing requirements. And even beyond that I find it important to keep the overall software development process in the picture.

“Clean code” or “Agility” or “Lean” are just labels to me. Following their canonical descriptions to the last letter drains the life out of them. Cargo cult is always lurking around a corner; it’s easy to mistake these means for an end.

I’m not peddling off-the-shelf trainings under these labels. Rather I believe in taking them as quarries to break useful advice from – and to add my own experience and views.

This – hopefully – results in my clients to do the same: to take nothing at face value, to constantly reflect and adapt, to make their own observations and experiments.

Ultimately my work revolves around being alive, being viable – and staying happily and relaxed in business.

What’s it all about?

  • Clean code development.
  • Writing software in a responsive, non-wastefulrelaxed manner.
  • Being reliable in what you do.
  • Making your software delivery more predictable and less a of matter of gut feeling.

That’s what my job is about.

Or to summarize it in one word: my concern is sustainability.

Because every code base, every developer, even every team and every company are resources. And resources can be used in ways so they last long – or they can be misused, even abused and burn quickly.

How I contribute

My way of contribution to improving the sustainability of software development is by teaching. Or more generally by inspiring and provoking.

Because even if I’m ultimately wrong in what I’m suggesting, I will at least be “rattling your cage”. And that might get your thinking unstuck. And that will hopefully get you into action – which then will lead to some change and improvement.

As a freelancer I’m by definition not part of my clients’ businesses. My vantage point is not limited by a particular organization’s culture, beliefs, traditions, habits, politics. That’s helpful to inject new ways of thinking and doing into organizations that feel stuck.


This article was updated on 02.02.2021