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?

Good Problems

As we hurtle through the beginning of this year toward our release date, I'm forced to contemplate the challenges Dyn-IT will face after launch.  All startups face the same administrative challenges: setting up legal entities, organizational infrastructure, funding, project management, budgeting, evaluating costs, online infrastructure, etc.

All businesses also have some type of marketing plan (even if that plan is not to market).  You have to have some way to attract attention and make your product or service desirable.  What happens when marketing organically starts happening for your product before you attempt to generate it?  This is what is known as a "good problem." 

At Dyn-IT, we seem to be having a rash of good problems.  Let me give you a little breakdown of the past 12 months:

• In March of last year, we started writing software for a startup.  The company never went anywhere, but we gained an amazing jump start toward the idea of EdgeVault™.

• In late September, we received an offer to work with a group of former co-workers to develop an application for their startup.  This also did not work out, but we put in a good deal of work and got ourselves that much closer to our goal.

• In December, we were approached by a company that wanted to build a new software platform.  Not only did they come to us with an idea, but also a customer base just waiting for a new platform.

• In January, Richard presented at the EPIConference.  As a result, we have had a steady stream of interest in EdgeVault™.  This totally blows our mind each and every day.

• Now it's late February and we have a goal in sight, clients lined up, and a launch date in mind.

We are extremely grateful for this, but I feel its important to point out that we have tasted our share of failures to this point.  Each time we learned valuable lessons that propelled us onward.  Every business owner will face their share of failures.  For those opportunities, I offer you the words of Ray Kroc:

"Press on.  Nothing in the world can take the place of persistence.  Talent will not; nothing is more common than unsuccessful men with talent.  Genius will not; the world is full of educated derelicts.  Persistence and determination alone are omnipotent."

Now we only have to live up to the hype and reputation that is building!

About The Architecture

Good Morning!

My business partner, Adam, asked me about the basic architecture of our application.  I proceeded to explain MVC, from an operational perspective.  Not how the code is organized, but how the operation of the application works.  How actions begin with the user, cycle through the system, and come back!

So, here goes...

• When the application loads up, all the js are loaded, and the menus
• So.. When you click a menu item. You run a public function in a name-spaced JavaScript file. An example would be clients.js. (clients.load)
• clients.load hides whatever is on the screen and fetches the index page for clients.  It does that by calling a URL, and post the response to a div on the page.
• All URL calls end up in the routes table.
• Thats defined in the routes directory in the application code.   (Web.php, I believe.)
• The route for /clients gets sent to the resource client route entry.
• Which goes to the client controller. 
• ClientController.php is in the controllers, and that particular endpoint triggers the show call.
• Resource routes have a standard base set of calls it handles. (Table is not standard.... That is why it has its own routes table entry.

Anyway... If you look... The way things work is that a user action:

1. triggers a JavaScript function, 
2. which calls a URL, 
3. which gets routed to PHP, 
4. which accepts the call and returns, 
5. either HTML or JSON, depending.

Several loops can happen... Then it all waits for the user to start some other action.

Notable exceptions include:

• Tables loads:  All table loads (/table) happen as separate cycles, and return JSON.  This is so the table load can return a single page, and can request sort, filter and page changes without redrawing the table.
• Select-list loads:  Where select-list options are either volatile, or long, the select list load is done as a separate (/selectlist) call, allowing for filtering.
• Table headers:  The table tool we're using requires the data to be mapped in the JavaScript, and we do this by attaching JavaScript blocks to the index page HTML.  
• Our application is multilingual at the user level, so only the server knows what language the header label should be in. 
• Some of our screens are user-configurable, so the table layout is only defined at run-time.

Adam expressed a concern about whether this was proprietary, and whether we should even do this as a blog post.  I said no... not only is this the proper way to do this kind of thing, but anyone who is not using this methodology isn't actually building a web application... Just a series of pages!
There are no secrets here... we even include the technologies we're using on our website:  Laravel and jQuery

Compromising With Your Platform

I don't like compromise.  Especially with my platform.  The whole idea is that, as a developer, my work stands above the competition with better ways to get things done.  Faster, smarter, more secure.

But, if I'm using a framework, I'm suddenly restricted by what I can do.  I either have to change my design concept to fit in the framework, or I have to bend the framework to my will.  Oftentimes, I can get the desired result, but I really HATE it when I can't get it to give me what I want.

Using a framework suddenly makes accomplishing my goal harder, rather than easier.

So, using a framework can make your project easier to develop up to a point.  Once you pass that point, using a framework can challenge you.

Don't compromise.  Force that framework to do your bidding. That's why its there.  And if time constrains, never accept your compromised design as a final design...  Plan to move to your original concept at some point in the future.

If you compromise on your design, then your design is compromised.  Keep that in mind.  That is not a word with two different definitions... that's a truism.

Development Timeline and A Developer's Axiom

Development Timeline

Software projects, like movies, are never finished, they're just released.  But unlike movies (unless you are George Lucas) software can be updated!

I write that, to write this...  The recombination exercise is completed, and the development team here at Dynamic Iterations is now writing new code to finish the initial feature set for EdgeVault.

And, that feature list is set.  Version 1.0.0 will have the Document Manager, the Contact Manager, and two components of the communications module, namely internal chat and email.

The bug reporting module will come out in an early future release, which we will be doing often.

Our Beta Testers and early adopters will have priority in deciding what features are needed, and which existing features can be improved.

Developer's Axiom

 Just because you can do a thing, 

doesn't mean you should!

Our customization effort includes form-building tools that involve using draggable screen elements to define a blank form.  This is also used to do the contact module designer.  Heady stuff, and we put some hours into getting it just right...  we couldn't find a plug-in that did what we wanted, so we made our own.

There was so much time invested in the draggable plug-in that I wanted to use if for other things, too.  In this circumstance, for the assignment of roles, users, tokens, etc.

But after the conference, after talking to people from hospitals, large practices, and other service providers, I realize that scalability, so much part of what we're building here, is going to kill this drag-and-drop interface that showed all the users in the system.

A visible screen element for each of up to several hundred users is  the very definition of cool and unusable.  We're talking Facebook Business Manager bad.
So, as cool as it is to use, when dealing with 6 users, 2 departments, 4 roles, and so on, when theres 200 users, 14 departments, and 26 roles, its unusable crap.

Oh well.  This is how software development works, and often, the simplest method is usually the best.