• Who is Rodney Giles?

Business - Software - Architect

Business Consulting

I have a sign hanging in my office:

People may not remember who you are or what you did, but they will always remember how you made them feel...

That old adage holds true even more for strategic business software. When you make people feel stupid because you don't understand their perspective, you fail to improve their performance or your bottom line. Likewise, if you coddle them and avoid making poor usage painful their productivity will fail and you will not impact their lives in any meaningful way. This is why we have to start with a proper appreciation of pain.

The goal of all good business software
is to make the business more
fun and easier to run...How we handle pain is actually
the secret to achieving this goal.

While user pain is not fun, pain reporting is essential to iterative improvement. Without pain, a system can be used improperly without repercussions. For example, a person could run on a broken ankle until their foot falls off if the ankle didn't scream in pain. In business, the lack of pain can kill productivity and eventually even the entire corporation.If we start by appreciating pain in your system we can easily direct your users and employees to the ideal workflow naturally and easily. It ends up avoiding long term stress on your business and promoting great usage patterns. This is the idea behind programing pain into your application.

This is one of the key concepts of business analysis that is often missed by less experienced software architects.

I know it seems counterintuitive. It can take a bit of discussion to get business owners to understand the importance of pain. But the proper implementation of pain in business is always essential to efficient business architecture. At the end of the day, you need business software that give you and your users just enough discomfort so that you avoid using it improperly.When we focus on putting pain in the right places, error messages become friendlier, source code becomes more concise and bug rates plummet because you have simple system that considers the user a partner in accomplishing its task. With pain users become more proactive in reporting problems. You get a chance to make them feel heard and valued. Even though there is initial pain, the end result is a happier customer.

Before we can build for efficiency, we have to understand the pain points.

I've found the best way to build efficiently systems is to start by putting pain in its proper place and then ensure the process has an appropriate response to each pain point. There is a true art in understanding when and where pain is effective in creating efficient processes. But without pain you cannot direct employees or end users do things in an efficient manner that actually finds relief from the painful processes.

This is why the ultimate secret to
making users happy is appreciating
the need for pain in the system.

Software Development

Software should never be built to replace humans beings. It should only be used to enhance their productivity and efficiency...

One of the important decisions in software development whether to let humans do the job or to augment their abilities with software. Requirements are never written clearly the first time because nobody asks whether humans can do the job better than computers. There are a lot of things that humans will always do better...

Computers are great at math.
Humans are better at moral quandaries.
Computers repeat things well.
Humans are better at unique interactions.

It may seem strange for a software guy to seek so hard to find reasons not to develop a piece of software. But that is precisely what makes me good at my job. I hate throwing resources at half-baked solutions only to throw them away later. I've seen this happen time and again because the process architect didn't take the time to think things through for a few hours first.

It is my sincere belief that
we should only build software
when there is no other way
to solve the problem...

For this reason, I always insist on understanding the why computers are better suited to do a task rather than humans. If people can do a job better, your business will be more successful if you let them do their job without clunky software to get in the way. It's always best to delay development until everyone can concisely articulate the impact we are trying to achieve. Once we can articulate impact, it becomes easy empower engineers to solve each problem they face while trying to materialize your vision.

It may seem strange for a software guy to seek so hard to find reasons not to develop a piece of software.

That is actually what makes me good at my job... I hate throwing money at half-baked solutions. For this reason, I always insist on understanding the why computers are better suited to do a task rather than humans. If people can do a job better, your business will be more successful if you let them do their job without clunky software to get in the way.

Everything is a tradeoff.
But generally, less is more.

Process Architecture

The most elegant solution to any problem is always to avoid the need to solve it in the first place...

At first glance this seems like a cop-out. But it is actually the bedrock of good design for business systems of all sizes. This is how we begin to work smarter rather than harder. Efficiency is always found and exploited by eliminating unneeded tasks.If necessity is the mother of invention... We should really spend more time understand the necessity in the first place. Too often companies spend millions of dollars trying to solve a problem which don't really matter. This happens when they forget to check for a way to sidestep the problem n the first place.

All good architecture starts with a solid understanding of the true foundation.

I find that drilling a team repeatedly on describing the problem until both the problem and solution can be described succinctly insures that both the software and business processes stand up to the expectations of your users.

it is always better to ask why like a broken record before building anything.

If we jump to building business solutions without understanding the precise and small thing we are trying to solve, we really end up building a Rube Goldberg machine with very little impact on the real world. Most problems are solved by simple machines that do one thing extremely well. If you find yourself in need a complex solution it may very well be that you have not begun to understand the problem yet.

If you give me a phone number and a reason to call, I'll do my best to get back with you. Please let me know any pertinent details like time zone and the **best time to call ** etc...

I Now consult exclusively through
codeheavy strategic Business™