Setup to Succeed

I've worked for both good and bad companies in my career.  Some companies treated their customers well, but treated their employees poorly.  These companies generally had high turnover, and little to no corporate culture.  Then there are those companies that treated their customers and investors poorly, but treated their employees like kings (I.E. the dot com companies pre-bubble).  They had unique and attractive organizational culture, but ultimately their model was unsustainable.  The entire world saw and felt the result.

What is the solution?

Dynamic Iterations has derived a very simple yet seemingly elusive equation that predictably yields success.  It consists of two steps:

First, provide the best service possible for your customers.  This simple concept is so often overlooked.  These relationships are the lifeblood of your business.  It is particularly important to keep a pulse on your clients when considering growth (when to, how to, etc.).  Always make sure that the people that brought the first dollar of revenue in your door are still deriving the same benefit and service they received on day one.  There is no day two.

Secondly, take care of your employees.  In big corporations, hard working employees often painfully learn the lesson that no one is irreplaceable.  However, if the leadership treats its team members like they ARE irreplaceable, you impart to them a level of pride and ownership.  You build a family.  When someone in that family faces a problem, it becomes everyone's problem.  If you take care of your employees, they will take care of your customers, and ultimately, your business.

Customer Focus + Engaged Employees = Success.

"Why" is not a bad question.

My children are in that stage of life when they are fascinated by the world and by knowing more about everything they encounter. It sometimes seems like I'm listening to a broken record when I hear the simple question, "Why?" fifty times in a row.  I love that they are curious, and I've endeavored to take that curiosity into my professional life.

In corporate culture today, people are often heavily discouraged, if not expressly forbidden, to ask why something is being done a certain way.  In other words, for the sake of a boss' ego, a perceived threat, or any myriad other shallow reasons, creativity is stifled, and innovation is squashed.  However, one of the luxuries and truly liberating aspects of running your own company is that no one can tell you not to do something.  After all, that's one of the things we all wanted out of being an adult.  "When I grow up no one can tell me when to go to bed" was a childhood thought we all had at some point in response to a mandated bedtime.  At Dynamic Iterations, we strive to foster that child-like curiosity, and never want to discourage innovation. 

It's OK to ask "Why?"

I've been involved in several start-ups at this point in my career.  Each one presents its own unique challenges and new possibilities.  Every time you come to a decision point on infrastructure, it is necessary to research options and reevaluate, because business and technology landscapes are ever-evolving.  Companies change, restructure, and sometimes disappear.  Technology gets better, faster, and cheaper.  To stay relevant, and save your bottom line, you must also evolve.

At Dynamic Iterations, we take the same methodical evaluative approach to our software design.  From which platforms to use, to innovative code configurations and methodologies, we constantly assess our options.  Just because we solved a particular problem a certain way in the past, does not mean that is the best approach for the current issue.  I'm sure it drives my partner crazy when I ask him why we are approaching a problem a certain way, but, in the end, we are always better for it.

Do I have to reinvent the wheel?

No.  This does not mean reinventing the wheel on every occasion.  Sometimes the way you did it last time is still the best way, and that's perfectly OK.  Not every problem will require a new approach, but you should still be in the mindset of considering whether or not it does.  Otherwise, your products will become stale, and your customers will become bored.  Worse yet, they may leave your platform entirely.

That's why every time our fingers meet the keys, we aim to provide the greatest solution available at that moment.  This is not only reflected in our work product, but also in the reactions of our clients when they see new features or enhancements to their platforms.  There is truly nothing like seeing your client's eyes light up and a satisfied grin appear on their face.  In that moment, you know the effort and commitment you have put into that relationship will be returned for years to come, and that's an indescribably good feeling.

The Urge to Refactor

Refactoring

The urge to re-factor your code base whenever you find, a new, more elegant, method to accomplish something that you're already written, can be strong.

Frequent refactoring is a vital part of keeping your code base fresh and current.  Also, when you come up with a new way to do things, refactoring can improve the performance and efficiency of your application,

Also, when your current model for doing things doesn't work, and you meet that challenge, refactoring can cut down on the one-offs that occur in code.

For the developer, code continuity improves readability and maintenance.  design alignment advances object orientation, and every performance enhancement, no matter how small at the unit level, improves the overall user experience.

For the product owner, more efficient code reduces operating costs, and readability reduces maintenance costs.  Better models are better. (thus the label)
And anything that improves the overall user experience... well, it improves the user experience.  Users pay the bills.

But, on the other hand...

Refactoring requires a lot of time and testing to accomplish properly.  Also, there's the possibility that your new solution may leave you with a one-off somewhere else.  And, it doesn't improve your feature list.  Your users probably wouldn't notice it., so the perceived value is minimal.

If the re-factor improves elegance, but not performance... or worse, degrades performance, then it's not a good investment.  readability is a strong variable, but it is a secondary variable.  At the end of the day, your Meat and Taters get delivered in the space between what the user pays you, and what you pay the platform.

IMHO

So, a balancing act is called for.  If the one-off is going to be visible to the user, or disruptive to usability in general, then the refactoring is probably called for, with high priority.  But don't let the perfect be the enemy of the good.

If it's a performance enhancement, then schedule the re-factor as a planned improvement, just like a new feature.  And then prioritize it over new features, especially if the new feature would benefit from the redactor. Promote the re-factor as a performance enhancement.  Besides, if the re-factor doesn't improve performance, then why are you doing it?