Who is Rodney Giles
I do not build robots to replace people!
Sure, I may read, write, and code proficiently in over twenty different languages, but my main passion is understanding people, customers and users. I love looking at processes and figuring out what makes them tick. I love dissecting business nuances and figuring out the most efficient way to do something. And I love building great software which aids people in building a better world.
I'm well travelled, well read, well rounded to almost any software scenario.
I love building software that connect people in new ways and brings business opportunities to many new entrepreneurs. I've worked in almost every sector of software including: Medical, Financial, Real Estate, Mergers and Acquisitions, Aeronautics, Public Relations, Advertising, Personal Management, Predictive Analysis, etc ad nauseum...I love stuffy research and ponderance on boring subjects. Although, nothing it truly boring. I find more joy in solving small problems than big ones. I've worked with lawyers in regulated industries more times than I can count. I enjoy digging into the implementation of things. How things work are just as important as how well that working is communicated.
I enjoy humanity.But I absolutely deplore computer games!!!People are much more interesting...
The Business of Technology
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 counter intuitive. 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 leadership. 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.
The Key to Good Software
Software should never be built to replace humans. It should only be used to enhance productivity, improve efficiency and make the world a better place...
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 and there are a lot of ways computers can help. Now more than ever with the advent of AI...
Computers are great at math.
Humans are better at moral quandaries.
Computers repeat things well.
Humans are better at unique interactions.
Computers keep records well.
...the list is infinite...
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 a month later. I've seen this happen time and again because software executive don't take the time to think things through the solution first. They are too enamored with the new shiny AI model and don't want to think through the Business use case to make sure they build things right.
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 and AI are better suited to do a task rather than humans. Often times they are. But if people can do a job better, your business will be more successful if you let them do their job without clunky software getting 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.
The EXEcutive Process
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.