Quality Goes in Before the Software Goes Out

Nothing is more aggravating on a software development project than quality issues.  Developers build software that works locally, but when promoted to a testing or production environment, it breaks in embarrassing ways.  Sometimes new features break existing functionality.  It is a special kind of horror and misfortune.  People who use software expect it to work and do not wish to struggle with quality.  As someone who has attempted to deliver software for over twenty years, I recognize this frustration and have a few suggestions on dealing with quality issues. 

In my experience, quality issues have three root causes; insufficient software craftsperson skills, poor continuous integration and deployment, and a lack of quality culture in an organization.  Each of these is difficult to confront individually but can make a software project impossible in combination. 

Software craftspersonship is something we do not discuss often enough in this business.  It separates the amateurs from the professionals in this business.  Craft is taking pride in your work and holding it up as an example for others.  Some people never develop that mindset comfortable to muddle through their career.  It took me over ten years to build a sense of craft as a software developer.  I came to the software craft movement and continue to support it to improve quality in software projects worldwide.  Development organizations should encourage test-driven development, SOLID principles, design patterns, and code refactoring.  These practices improve quality, and it increases speed to market with better quality. 

The next cause of poor quality is the absence of continuous integration and deployment in organizations.  Software requires plenty of supporting structures to operate.  Configuration files store variables, configurable databases, and libraries help automate work.  On one machine, it is easy to maintain, but changes can quickly get out of control with multiple developers.  It is why having a source control took is a necessity.  Next, an automated build system should be in place, so when code returns o source control, it is compiled and deployed to a testing environment.   Finally, the same number of zeros and ones should move to other domains like copying and pasting a document.  The development team should alter database settings, libraries, and configuration files, but the compiled code should never change.  Approaching software deployments like this will save you numerous sleepless nights.  

The last thing hurting your quality is the culture of your organization.  Developers should be restless when looking at code, looking for ways to make it easier to read, debug, and maintain.  Refactoring should be a regular part of a developer's job, and the organization should understand refactoring code allows for better quality.  Developers should respectfully inspect each other's code to help others improve.  Each new piece of code should generate a unit test and every defect discovered.  Finally, developers need to treat quality assurance professionals with respect and like the first customer who views their software.  I believe this is the most laborious process in quality improvement, but you can move mountains with a healthy quality culture.  

Improving your organization's software quality is a matter of business survival because the release of buggy software undermines trust within your organization and, more importantly, with your customers.  Business partners will be more reluctant to purchase upgrades or use your automated systems because they do not trust them.  A few pennies more of software quality will save you pounds of frustration.  

Instill a sense of craft in your software development team, put continuous integration and deployment in place, finally breed a quality culture in your organization.  Otherwise, you have are doomed to live a life of aggravation.  

Until next time.  

Start Writing Unit Tests!

It helps when you test your code.

Software development is a difficult process.  It is filled with trial and error.  Developers must contend with vague requirements and impossible timelines.  It explains why the profession has a high failure rate.  I think we can do a better job and today I would like to discuss the easiest way to help reduce failure.

When I first learned about software development, the notion of software testing was primitive.  Often software testers manually went through the software attempting to find bugs.  It was a tedious and time-consuming process.  Automated testing began to pop up in the world of JAVA and then spread to the Microsoft world.  At first, developers chaffed at writing unit tests calling it extra work and unnecessary. 

After the initial resistance, the engineers and developers began to see the importance of unit tests.  Unit tests ensured the code functioned when checked back into source control.  It also made sure a change in one part of the code would not break a different portion of code.  Automated testing had another impact.  Manual testing became unnecessary and if freed up people to deliver more value in the organization. 

Automated testing not only cut back manual tests, but it also makes the release of software faster.  What usually would take three weeks to release could now take as little as three weeks.  Thus, automated unit testing reduced labor overhead improved the quality of software and increased the time to market for software.  Instead of chaffing at writing a unit test, the real question is why you haven’t started writing them.

Until next time.

All about the craft of Scrum Mastery

A good scrum master is like a good camp counselor

I take inspiration from plenty of people online and if you have followed this blog for any length of time you will realize I am not afraid to cite my influences.  I have also been a brig proponent of Scrum Mastery being a profession which requires more than showing up to the office.  This week, I want to talk more about the craft and business of being a scrum master.

I have said before being a good developer is in many respects like being a good jazz musician. You can say the same about being a scrum master.  A scrum master must have some technical chops and be able to perform their duties regardless of the situation.  You need to be prepared for anything and flexible enough for when the unexpected happens.  It is hours sitting around with developers active as a “rubber duck” to help them solve problems.  It is listening to them vent about frustrations. Finally, it is about continuous improvement.

It is not an easy job.  One moment you are a therapist for a developer and the next you are disciplining a product owner who is not doing their job.  I have had moments of deep rage where I find myself shouting at my house plants.  The anger is contrasted with sublime satisfaction knowing I am shipping software and helping the business meet customer needs. I have experienced every emotion between these two polls.  Each day is a new adventure and series of emotions to experience.
Companies are looking for scrum masters at an increasing rate because they are struggling to meet increasingly challenging customer demands.  They are also attempting to take dysfunctional cultures and transform them into something where people are willing to innovate.  They want to turn the peasant farmers who labor in their cubicles and transform them into warrior poets.

It takes strange and caring people to lead this kind of charismatic change.  The ironic part is these individuals are often entrepreneurs and iconoclasts who do not mesh with corporate culture.  I am sure every scrum master has a story about visiting the Vice-President's office for removing an impediment and ignoring the office politics.  I have discovered most transgressions are forgiven if you are getting software into production.

So being a scrum master is both a profession and a craft.  I would not have it any other way, and I am looking to help other people understand this career.

Until next time.
 
 

Say No to Ugly Metrics

One of the perks of my job it that I get to interact with plenty of talented and smart people.  One of them is Andrew Keener and I had the opportunity to spend a few hours with him over beer to discuss game theory, the philosophy of social contract theory and metrics to improve scrum teams.  It was heady stuff and I enjoyed every moment of it and wanted to share a little of the experience with you.

Keener has a very in depth discussion of scrum in metrics on his blog on linkedin.  I will let you read that on your own.  This week I wanted to discuss his notion of ugly metrics.  According to Keener, an ugly metric is one that reinforces the dysfunction of the organization rather than provide a means to improve performance.  Business people want to measure productivity and provide objective measures for how the people under them are doing.  The trouble is that for a creative endeavor like software development it is hard to come up with meaningful ways to do the measurement.

I try to track things which are concrete like bugs in production, how many story points successfully completed by the team, and number of stories flagged as technical debt by the team.  This way we have a means to see where we are and how we can improve. If I started using these metrics as a means of performance then my developers would begin to game the system to drive up their numbers. This inspired the famous 1995 comic strip from Scott Adams below.

So as a scrum master it is our duty to measure things which are relevant to our teams.  It is also important to use those measurements to inspire positive behavior and performance rather than encourage dysfunction in the team.  Otherwise, you are no different than the pointy haired boss Scott Adams loves to mock in his comic strip.

Until next time.

Are these factors holding back your agile adoption?

When the emperor has new clothes we need to speak up.

Once in a while I see something and it inspires me.  I get fired up and feel like ranting into the night like some kind of crazed deviant looking for windmills to joust.  This week I had one of those moments and it steeled my resolve.  I am an Agile professional and I want to help change the way people work.  

It all began when I read a fantastic blog post from Isaac Socolick, talking about Legacy thinking versus Agile thinking.  This got me thinking.  It has been fifteen years since the agile manifesto and plenty of business organization are struggling to adapt to the new paradigm of how business works.  I have been part of this effort for the last six years.  Why is change so difficult for these organizations? I have a few hunches.

Legacy Funding of projects-

At large organizations products are funded on a limited basis.  Teams are funded, spun up and then they are wound down once the project is completed.  This is a standard water fall approach.  Once the project is completed then it was folded into the support stack of the organization to be forgotten.  No consideration for Net Present Value is made.  Often input for what the customer wants is ignored and the project is seen as a test for a project manager or executive who wants to advance.  Finally, the process is managed not by operations people who understand the business but by accountants and CPA’s who understand pushing money around the firm.  So projects are funded with a thrown together team, with a defined deadline, and with limited input from the customers.  No wonder projects fail so often in corporate settings.

Quid Pro Quo behavior –

I have mentioned this before in this blog but bureaucratic organizations are organized around rules and favors.  The rules are covered by regulatory compliance and common practices in the organization.  Favors are people deliberately circumventing those rules in order to accomplish something.  This sets up a system of favors which makes the Tammany Hall politicians of the nineteenth century look like pikers.

This forces business leaders to trade favors with each other to accomplish personal and business goals.  Many of these favors happen under the noses of leadership because to expose these favors would open the firm up to scrutiny from regulators or worse upper management.  So what happens is a “Tit for Tat” or Quid Pro Quo culture were executives do favors for each other rather than focusing on the customer.

Ego Driven leadership – 

Since Lee Iacocca took Chrysler in the early 1980, a new kind of business leader has emerged.  This was the business person and celebrity.  They were in the company commercials.  They spoke for the company when asked to testify to congress and they behaved like monarchs running their business empires with imperial control.  Unfortunately for every, Lee Iacocca there were numerous failures such as Carly Fiorina, Al Dunlap, and the most infamous Ken Lay who transformed Enron into securities fraud and criminal organization.

People seeing this trend in business decided to jump on this bandwagon.  These executives in training began worrying about their own personal brand rather than how they were going to run the business.  They discovered with a few accounting tricks they could cover up, poor sales, a lack of customer service and poor innovation.  They further burnished their credentials by leading legacy style projects which improved their brand but did not help the business.  Developers have had a name for this for years, they call it "ego driven development".  Well ego driven leadership is the byproduct and it is hurting businesses all over the world.

I got involved in Agile and the reformation it is leading in business for six years.  I have the enthusiasm of a new convert but I know that trends like the above are going to hold back the necessary progress which we are trying to achieve.  We need to expose these obstacles in order to remove them.

Until next time.

How my agile is changing.

Those of us in the agile community spend a lot of time talking about building software and helping our business partners.  What I have discovered over the last six months is that for a large organization like mine agility is a relative concept.  What I am discovering is that the business is struggling to keep pace with the developers.  This week I want to provide a few helpful tips to explain how you can help your pals in the business keep up.

Have a release plan – 

Software projects in my organization have a budget along with a beginning, middle and end according to the executive leadership.  To the suits at corporate, they don’t know or care about sprints, iterations, and burn downs.  So we have been forced to come up with a bridge document between the backlog and what the leadership expects.  This is the release plan.  Since my leadership does not understand the terms epic, theme and story; we substituted the words milestone, feature, and story.  This made it easier for the executives to follow along.  In our backlog we organized everything by milestones then placed features under them and finally had stories under those.  What happened was a revelation.  The business owner knew what was expected to be completed and then wrote stories to accommodate that structure.  Sprints were now planned around delivering features and we were doing better at delivering what the business wanted instead of what the business owner wanted.

Metrics –

Professional athletics is concentrated on metrics.  How fast you can run.  How high you can jump.  How many interceptions you throw during a football game.  The game of metrics has been transformed by the practice of sabermetrics and “Money Ball.”  Development which is done primarily by engineers has been very poor at measuring performance.  This is why I have started to measure the team velocity in story points.  I am also comparing the amount of work scheduled versus the capacity of the team.  This provides the team with positive reinforcement along with upper management a way to gauge how we are doing.  I will also be doing more advanced things like comparing bugs with velocity and understanding if we have good code quality compared to team morale.
 

Developer and Scrum Master training –

I find it interesting that we are working on software which runs the business but the developers and scrum master do not know a lick about the business.  That is changing.  I am spending about 90 minutes a week learning the business with people on the front line.  This training will become a training program for all the developers on the team.  Each of us working on the project should be competent enough to work as an entry level employee using the software.  This is a new experience for me and my developers.  I don’t know why we did not think of it sooner.

Tender loving care for the business owners – 

My organization has had a spotty record with business owners.  They have taken a training course in how to be product owner and then they have been left to fend for themselves with little direction from their business units or help from the scrum teams.  I have made a point of each business owner I work with giving them a copy of Roman Pichler’s fine book “Agile Product Management with Scrum.”  I also spend time with them helping them groom stories so that the developers know what they are doing and can deliver that in one sprint.  I help them tie stories into the release plan.  The product owner has one of the hardest jobs in an agile organization.  Your scrum team will not succeed if the product owner doesn’t.

The most important part of the agile manifesto is to adapt to change over following a plan.  Well we are changing and this is how we are doing it.

Until next time.

Why do we treat customers like users

It was a big week in technology.  Microsoft had a massive press conference to promote its new operating system.  E3 had a big technological breakthrough which will lead to new products which I will share more about in a later blog.  Finally, there was the state of the Union address which almost devolved into playground insults.  It was not a bad week.   What struck me most about the week was a tweet from Yahoo technology critic David Pogue he said the following,

Microsoft CEO Nadella just now: “We want users to love Windows.” You could start by not calling us “users.” http://t.co/kgtlt2Ux15
— David Pogue (@Pogue) January 21, 2015

The over-caffeinated pundit from Yahoo is right there is something wrong with software engineers because we refer to our customers and consumers as if they are drug addicts instead of full partners in the software experience.  This week I want to talk about that.

The term “user” has been around as long as I have been working as a software developer.  My suspicion is that I can trace its origins back to the early days of corporate computing.  Large Mainframe and AS/400 systems housed tremendous amounts of data centrally and the “operators” of these systems the network administrators and programmers allowed “users” to run programs to gather data.  Ever since the 1960’s, the term has stuck and I feel it poisons the relationship between those who make software and those who use it.

Since the first moon landings, the powerful computers which took us to another world can now conveniently fit into a contemporary smart phone.  Instead of mainframe systems, we have the internet and cloud based computing.  In addition, an entire generation has grown up swimming in technology.  Sadly the habits and attitudes have struggled to catch up.  Daily, I see developers use the term “users” to refer to the people who depend on the software we create.  Users are stupid, selfish, clueless, and careless in equal degrees and they are the bane of the life of a software engineer because they are constantly breaking their creations.

I understand this feeling.  I spend hours working on software trying to get it to work correctly and then someone comes along and breaks it with little or no effort.  It is part of the sense of pride and skill developers have which allow us too figure out how to bend technology to our will. When someone dismissively breaks that technology, it creates a spiral of rage inside me which is difficult for me to explain.  That software is my “baby” and for someone else to call it defective or ugly is a serious insult.

What we do not talk about is that the “users” are really not trying to break our creations or insult our intelligence.  They just want things which work.  They do not plug in a lamp worrying about amperage or voltage.  They just want to plug in a lamp and have it light the room.  Software is supposed to solve problems and help make the day go easier and faster.  They should not have to worry about out of memory exceptions or properly filling out forms.  They just need to use the software on their computer, mobile device and tablet.

They are not users of software; they are consumers and customers.  Those of us in the software profession need to remember that and treat these people accordingly.

Until next time.

The Virtues of Agile: Respect

This is part two of five of our series of articles about the virtues of Agile.  This week we cover the topic of respect.

Of all the values of Agile, I think that respect is the most difficult to define.  I believe that this is because it is the one virtues based on emotion more than any other.  You cannot force a person to respect another person. It is a situation which develops over time when two people work together.  In high pressure atmospheres, like technology, respect can also be fleeting.  The person you respect today could be a colossal impediment tomorrow.  It is a difficult quality to cultivate and develop among professionals.

In my experience, it is also difficult to give respect to others because for most of my life as a professional respect was something which was earned.  Someone did not receive respect from you until they earned it by helping you or accomplishing something worthy of respect.  I remember this being the case during my years in debate and I also saw it in the realm of technology.  People who understood how to implement technological solutions were elevated above others and were granted respect by junior developers.

Since I have been a scrum master for the last year, I have seen that respect is not something earned from others but something you give others and they repay in back to you.  Respect is a virtuous cycle which reinforces itself with in the team.  This is not just about knowing the names of the people on your team.  It is about knowing if they have children and what they are doing.  It is about giving time off for them to attend Christmas programs.  It is also just shutting up and listening to people.

This is contrary to much of the leadership advice we receive from public figures like Donald Trump or Kevin Trudeau being leader is not so much about being in charge but being a servant.  A leader serves the people he is supposed to in charge because the only way that they succeed is by helping others instead of being a selfish jerk.  It also means that you are going to have to swallow some pride and learn to work with others who seem impossible.

It has become obvious to me that most of my problem employees are not really problems per say but they are having problems with their job and it is my duty to fix them.  A developer accustomed to cut and paste programming was floundering, after a few training courses and working with MVC5 and Typescript they are a dependable member of my team.  In addition, he volunteers to help in situations I was not expecting to contribute.  It happened because our relationship moved away from conflict about him not hitting sprint goals to him actively participating in the team.

I am not perfect on this front.  I struggle with names on a regular basis and I have to suppress my more narcissistic tendencies.  Some people I have a very difficult time respecting because they have toxic personalities or are self-centered but I try and hope that a little dose of respect will go a long way.  Respect is not easy but if you truly want to have it on your team them you are going to have to provide it to you team members.

Until next time.

No BS, Why people are software developers.

We don't write the software for the money.

Software developers are and odd breed of people.  We work long hours and view the world through the lenses of code.  Why do they do it? I have been thinking about it for some time and I wanted to share with you why software developers do what they do.  This week on the blog what drives software developers.

One of my favorite books on the subject of software development comes from the Bill Pfleging and Minda Zetlin called “The Geek Gap”.  The principle thesis of the book is that software and engineering professionals are motivated by building things that work.  Business people are motivated by influencing others to get work done.  Often these to world views come into conflict.  This is because business people are motivated by schedules and business needs while technical professionals are motivated by building systems that work and our easy to maintain.

I have experienced that conflict first hand as developers have argued with management about unrealistic deadlines and management has looked at the creative process involved in software development and groaned in frustration.  This is one of the reasons why agile software development has been so successful.  The role of Business owner has acted as a “go-between” role between business people and the technology staff and it has helped smooth out the rough edges between the two different tribe of business groups.

That still does not answer the question of why software developers do what they do.  David Graeber, a professor of Anthropology at the London School of Economics wrote a provocative essay “Bullshit Jobs” in the article he argues about the growth of jobs which seem to do nothing more than being involved in meetings, filing reports and administrative support to the business.  Software development is the antithesis of the “bullshit job” because we are building actual things which people use- software.  Granted it is not the great American novel or a cure for the myriad kinds of cancer that exist, but every phone app, web page and application you use in business was created by hand in the mind of a software developer.

This creative process of wrestling code into something that people will actually use is pretty awesome when you experience it.  Four or five hours can drift by and it can seem like five minutes.  You are in a state that developers often refer to as flow.  When you are in flow, I compare the experience to having the hand of the creator guiding your mind toward a better solution.  It is one of the most sublime experiences that I know.

This is one of the reasons I founded my own software company.  I wanted to share that sublime experience with others and help them do better business.  Give us a call and we will show you how.

Software developers are an odd breed of people but by understanding that we are a building things people use and are not involved in “bullshit jobs”; it is one of the best professions to be involved in.

Until next time.

Graduating from BizSpark

Proud to have graduated from BizSpark

This week marks a special anniversary of sorts.  Three years ago I became a Microsoft BizSpark member.  This week I graduate from the program.  It has been a peculiar journey but I feel that I have learned a great deal.  I would like to discuss my experiences with the program.

I was between consulting jobs and was attending an ALM conference in Chicago when I asked if there was a program for a Microsoft professional to get Visual Studio in order to start building a software start-up.  I was quickly directed to the BizSpark program and I have not looked back.  I was provided with software licenses for Office and Visual Studio.  I was also given a network to share ideas and solicit for help.

It has not been perfect.  Sometimes I have felt alone in the wilderness of business.  The clients I thought I would get just by putting out a shingle have been elusive.  Still, I have been able to migrate from Visual Studio 2010 to Visual Studio 2013 and keep up on all the latest technologies.  I am now comfortable with MVC thanks BizSpark.  I have embraced Microsoft Tag until Microsoft decided to abandon the technology and thanks to NuGet was able to generate my very own QR codes to manage my business.

Plenty of ups and downs and BizSpark has been there for me.  Now I am officially an alumni of the program and I hope that I get an opportunity to follow in the footsteps of another member WhatsApp.  I understand that this is pie in the sky thinking but that was why I wanted to be an entrepreneur in the first place.

Feel free to contact us and learn more about our business.  I want to take time out to thank Doug Crets and the BizSpark team for sharing my work with others and keeping my focused on the end goal which is quitting my day job and putting other people to work.  I look forward to letting everyone know when that happens.

Until next time.

Death to Performance Appraisals!

Performance Appraisals are about as
 helpful as slapping your employees

It is that time of year again.  We are hustling to and fro and feeling like we are running in place.  You may think that I am talking about the holiday season, but the reality is a more grim corporate ritual.  It is the return of performance appraisal season.  I hate performance appraisal season.  I hate it like a young child hates liver or a dog owner despises animal cruelty.  I do not see any benefit to having them in a business environment and I certainly do not see them doing any good in an entrepreneurial environment.  This week on the blog, I would like you to indulge me as I explain why I hate performance appraisals.

At an early age we come in contact with the performance appraisal, it was called a report card.  These pieces of paper and notes home to our parents were necessary to let them know how we were doing in school.  If you were lucky you had parents like mine who were involved in your education and had a fairly good relationship with my teachers.  If you were like other students I knew your parents would be surprised each time you brought back your quarterly report card.  As you grew older report cards were a means to perform educational triage.  Hard working and gifted students were moved to the front of the line for college preparation and scholarships while those who didn't measure up were cast aside like trash.  Grades determined your official status in school and your possible desirability to go to college.

Flash forward four years of high school and another four years of college and when we get into the job world we expect to be free from the tyranny of report cards.  Instead, report cards are replaced by performance appraisals.  Unlike report cards, performance appraisals are not based on objective standards of excellence.  They are based on the economic needs of the company.  So you could have perfect attendance, not miss a deadline, and generate millions of dollars of sales and still receive a “meets expectations” on your appraisal.  For a classic example of this kind of insanity, just take a look at Microsoft and its old stack ranking appraisal process.  I feel very strongly that Microsoft hurt its ability to retain good employees and innovate because of this system; if everyone “meets expectations” and then the company really can’t meet the expectations of the customer.  So good employees leave and mediocre and poor ones stay.

There is another reason I hate that hate performance appraisal and that is because it resembles management by fear.  According to W. Edwards Deming, the godfather of lean manufacturing, one of the seven deadly diseases of management is the use of Evaluation pf performance, merit rating or annual reviews to control employees.  People are not dumb, and if they know the metrics you are using to evaluate them they are going to game the system to get the best rating possible at the expense of the business and customer.  For instance, if you reward a bus driver for on-time drop offs they will avoid picking up more riders during high traffic periods because that will affect their drop off times.  This creates perverse situations where people are rewarded for poor customer service.  People are afraid to do what is right for the customer instead they do what will be appraised in a positive fashion.

I am not against rating people and their performance, but the way we do it now reeks of mental illness.  Managers should be in contact with their line employees daily providing coaching and encouragement.  When a performance issue comes up it needs to be addressed right away instead of during the appraisal process.  Immediate feedback when you screw up is much more helpful then trying to recall what you did during the middle of the fiscal year.  Agile teams need to know how much velocity they can perform and if they are improving it.  Sales people and marketing professionals need to know what is going on the top line of sales and how much margin you are making on the bottom line.  All of this data is important and necessary, however you cannot squash it together into a gooey ball of muck an use it to objectively rate an employee. I would much prefer a manager telling me that the firm could only afford a two percent raise than telling me I met expectations and that is worth two percent.  The honesty would be bracing.

So what do I propose as an alternative?  I am a big fan of development plans.  Every 90 days a manager should tell a person what they can do if they need to improve and what they need to do if they would like to advance to a higher position.  In six month intervals, this information should be written down and then saved for HR purposes.  This way over the life time of the employee there should be a record of the growth and development of the employee without the capricious rating system that most companies use.  This forces managers to manage their employees instead of kissing up to their superiors.

At the end of the day, a business must satisfy the needs of their customers.  I strongly believe that the performance appraisal process as it exists in contemporary companies satisfies neither the needs of the employees or those of customers.  Something must change and I hope that as my business grows I will be one of the people leading this change.

Until next time.

A simple thought

I consider myself very fortunate.  I have a day job and in the evenings and weekends I pursue my dream of being an entrepreneur.  During my life, I have had the good fortune to have people encourage me and help me live up to my potential.  As I continue this journey as an entrepreneur, I understand that I will have to give back. 

This week’s blog is not going to be very long. I just want to reaffirm my statement to everyone who has been following that as we grow we will also use that growth to help others. It is the very least that I can do.  Please reach out to us and find out how we can help your business.

Until next time.

To Big to Succeed

People have a right to get upset about
Healthcare.gov

Like many people in the technology business, I am following the news of the roll out of the Healthcare.gov website with a mixture of horror and disbelief.  It is clear to me that the current occupant of the White House deserves some criticism for this roll out; however, I also think a huge dose of criticism should be leveled at CGI International who is doing the principle development.  In this blog, I want to discuss why consulting companies like CGI International are too big to succeed.

In the book “The Geek Gap,” Bill Pfleging and Minda Zetlin say that technical leaders and business leaders view the world on very different terms; the business leader is interested in control and influence while the technical leader wants to build things which work.  It is clear to me that CGI is more interested in influence and control than building working software.

During congressional hearings with representatives from CGI about the Healthcare.gov roll out, no project managers were discussing the problems encountered.  More aggravatingly the congressmen did not know which questions to ask.  So you had people who negotiate contracts attempting to justify why they should get paid to people who did not understand what they were paying for.  It was depressing.

What makes this even more frustrating is that there are great examples of technology and government working together.  Each year Intuit makes millions of dollars helping people do taxes.  They are able to wade through the income tax regulations and each year release software which helps people do their taxes.  Even if the law changes, they are able to update the software over the internet.  If Intuit can do this each year why can’t CGI?  This answer is that CGI, from the outside looking in, is the antithesis of an agile organization.

They value process and tools over individuals and interactions.  They are more concerned with obeying the letter of a contract that providing collaboration.  Finally, they don’t have working software but they have plenty of documentation of why they should be paid.  Of course, this does not matter because, CGI is highly successful and so deeply embedded into the project that firing them for a poor job would be foolish.  In essence, they are too big to fail.

I had a hunch something was wrong when I reached out to my local congressional representative by e-mail and phone offering to pitch in and author some web services.  The congressional office had a staffer contact me and assure me that everything was under control.  When I asked if there was a way to volunteer for the project, I was instructed to follow the federal procurement process.   As a two person technology start up, I decided that it was not worth the hassle to get further involved.  I am sure that other start-ups felt the same and that is why firms like CGI make money.  They provide lousy service but they understand government procurement so they do not need to excel at fulfilling contracts only closing them and getting paid.

Healthcare.gov could have been a smashing success out of the gate, but thanks to a bad procurement process and a firm like CGI, it began with a thud and is slowly being made functional.  I hope that the November 30th release is a huge success.  I did not go into business to become CGI; I went into business to build things which work and solve problems.  I hope this is an object lesson to our elected leaders being able to win a contract does not mean that they can actually do the work.

Until next time.

A Thanksgiving Message

It is Thanksgiving time and all of us at E₃ systems are going to be taking time off to spend with our families and friends.  I want to devote a little time to what we are grateful for this year.

2013 has been a year of transition for our little company.  We have launched need products and jumped into new directions as the market has needed it.  I am very thankful for the talented people who provided help and direction during this time period.  I would also like to take time to thank the people in the Joliet Chamber of Commerce and Microsoft Bizspark for believing in our organization.  I also want to take time to thank the Will County farm bureau for its help in helping get the word out about our product.

2013 has been a year of transition for E₃ systems but we look forward to the new year and hope that you are part of the energy and excitement.

Until next time.

Why You Need Tony

Tony is looking after your fleet.

After the work we put into our new Tony Fleet Maintenance program you would expect us to drop the mike and do a little celebrating.  Far from it; this week on the blog I want to talk about why you need to use this application.

If you are safety coordinator at a business or owner, insurance companies and regulatory agencies are demanding that you provide information about the maintenance of your equipment.  This is going to be particularly important if one of your vehicles gets into an accident.  Before Tony, you kept track of this information on paper or with an excel spreadsheet.  Now you can access this information with a few clicks on a PC, tablet computer or smart phone.

So when you are called to the scene of an accident by the state police you can bring along your smart phone and show the officers that all of the maintenance on the vehicle is up to date saving you potential liability.  Our system also makes it possible to settle disputes between the shop and the company.  You can find out how long work is under warranty and if something breaks prove it to the shop that they need to fix it.  So now your organization is saving money.

Finally, Tony makes it possible to save time.  Since it is cloud based system, it works on any device with a connection to the web you can enter information anywhere or any time.  You do not have to be in the office and can enter data at home or on the road.  This kind of system is perfect for people who would rather be meeting with customers instead of being tethered in the office doing paperwork.

We are pretty proud of this application and are looking forward to going out and selling it in the agriculture and logistics community.  Contact us here for more information.

Until next time.

Introducing Tony - Our Latest Product

Your Fleet Maintenance never looked
so good. 

More than cash, the common currency of an entrepreneur is trust.  If customers and client can not trust you your business is doomed to failure.  Today we at E₃ systems are proud to announce that we are releasing our Tony fleet management system.  This week’s blog post features our new product and how we kept our promise to our customers.

Tony was conceived in February of 2013; as we looked at the marketplace and realized there was no good tool for tracking maintenance on a fleet of vehicles.  Trucking companies, school bus services, rental car companies and farmers did not have a good tool to keep track of when and what kind of maintenance they did on their vehicles.  We decided to write one.

The system like all E₃ products works on a smart phone, tablet or regular PC. It is based on the cloud so there is not software to install or upgrade.  Finally, we made our system easy to use and economical for consumers.

With Tony you can QR code your vehicles so that anyone with a smart phone can view the maintenance history on a vehicle.  Paperwork is a thing of the past as a few key strokes can pull up a vehicle and the history of maintenance for it.  In addition, when you are confronted with law-enforcement or insurance requests for vehicle maintenance you can provide them with that information from any device with a web connection.

We went through an exhausting testing program to make sure we had a great product to offer you.  Now we are pleased to say it is here.  Contact us today and we will tell you more.  This is just one more way we are trying to earn your trust.

Until Next time.

The Quality Goes in Before the Software Ships Out.

I think we need to explain.

This has been an amazing week of transition for E₃ systems.  We have formally been in business for three years.  We are also on the cusp of a new software release. Today I want to talk about our new product Tony and why you will have to wait a little longer before it goes live.

Early in 2013, a potential client called us out of the blue and wanted to know if we could put together a simple contact management system for them.  We rushed a prototype out and demonstrated it to the client.  They seemed enthusiastic until we gave them a contract and said that they would have to pay for us to finish the project since it was done on spec.  We never heard from that client again.  I suppose this was a good development because if they were not going to return our calls or honor a contract I am sure that getting paid would have also been a serious problem.

The months of March and April were gloomy as we continued to sell our main product Sully 2.0 and assess the failure of our prototype project.  Some good did come out of the work because; we developed experience in MVC 4 and Entity Framework code first for rapid project turn around.  By May, we had come up with a new project and idea which we nick-named Tony after a famous Fiat mechanic.

Tony would be an easy to use system to track maintenance for vehicles in any sized fleet. Trucking companies, rental firms, and even car dealerships could use the system to keep track of when and where work was done.  It would become a living record and best of all it would obey the philosophy of all products at E₃ systems.  It would work on a smart phone, tablet, and personal computer.  We also leveraged the power of Microsoft Tag so someone in the field would scan a code on their phone and get instant information.

We had scheduled that Tony would launch in July of 2013.  It was a hectic schedule made even more dramatic by the server migration we did to upgrade our software and databases.  Something had to give and it was clear that the migration took precedence and that we would have to push back the release of Tony.  We also felt that we needed to do more work on the product before it was ready for release and sale.  I am deeply disappointed about this but as the president of the company I would rather ship quality software that release something and then expect my customers to find bugs and act as our quality assurance team.

So we are planning to release our Tony software in mid-September.  I felt that you our customers deserved and explanation.  We had been dropping hints about Tony for the last two months and felt you needed an honest explanation of why it is not here.  As a young start-up we are not in the business of vaporware so please forgive us for the delay.  If you have any questions or concerns please drop us a line and we will have an account executive contact you directly.

Until next time.

We upgrade so you do not have to

Pay attention! We are upgrading.

This week we are preparing for the launch of our new software product nicknamed “Tony.”  We are also upgrading our servers from Windows 2008 to Windows 2012.  This made me think about why you the small business person should care about all these behind the scenes moves.  Today’s blog post will cover the reason we upgrade at E₃ systems.

One of the important powers of the web and cloud computing is that as a consumer of cloud services you do not have to worry about software, server space, or even operating systems.  All you have to do is open your web browser use the software.  It is up to the loud service provider to make sure that its systems are up and running rather than placing that burden on the consumer.  This is why we are upgrading.  We upgrade so you the consumer do not have to go through the experience.

It is up to us E₃ systems to make sure everything works in a safe and secure fashion.  It is up to us E₃ systems to bring you the latest technology including responsive websites which look good on tablets, mobile phones and regular PC’s.  It is up to E₃ systems to fine tune those systems for maximum performance.  For our customers, they can worry about their business and leave the upgrades to us.

This is not the most glamorous thing about being a cloud based company but I think it is the most important. We do upgrades so you don’t have to.  Manage your business we will worry about the upgrades.

Until next time.

Is your business ready for the next SharkNado.

Are you ready for the Next SharkNado Attack

It you missed it last week of the biggest events on Twitter in a long time was the premier of the B-grade monster movie SharkNado on the SyFi channel.  As the title implies, it was a monster movie featuring man eating sharks which sucked up by a tornado and then dropped on the unsuspecting population of Los Angles.  News anchors from cable television, celebrities of all stripes, and political figures chimed it to remark how awful the film was.  It generated so much buzz that the network decided to rebroadcast the film early because the overwhelming demand.  There is a lesson here for any business person.  The web and social media can be a powerful thing creating demand for your business.  In this blog post, want to encourage you to be ready when the next SharkNado hits.

The universe of social media is composed of many services; Facebook, Twitter, and Reddit being the largest and most influential services on the web.  Facebook acts as a global community for everyone from your parents to people who are interested in dressing up as cats to go for contact.  According to Yahoo news, about 1.1 Billion people call Facebook the place they go to share information with friends and family.  Twitter is known as a micro-blogging service and users can only type 140 characters at a time.  What makes Twitter so popular is the speed of how information is shared and it is also relatively unfiltered so it is the tool of Occupy Wall Street and rebels in Turkey.  Rumors and misinformation swirl about but within this river of information are plenty of nuggets of information gold.  Watching Samuel L. Jackson root for team USA during the Olympics was extremely funny and I highly recommend Jack Tapper’s feed from CNN.  Finally, Reedit acts as a clearing house of blogs and photographs on the web. They also have an “Ask Me Anything” or A.M.A feature which has become the place for politicians and other thought leaders to try out new ideas.  For the sake of disclosure, I use Facebook, Twitter, Google+, and LinkedIn as my social networks to promote this business.

So what does this mean to you a small or medium sized business? It means you also need a presence on social media web sites; at the very least Twitter and Facebook.  You can promote specials and talk about your business in an unfiltered manner.  If people like your content they will share your tweets and Facebook messages extending your reach.  It is also cheaper than advertising on radio, television, or newspaper.  This makes it a low cost means to promote your business.

We at E₃ systems understand this strange world and would like to help you.  We leverage Facebook and Twitter and can show you how to do the same.  Please contact us and we will show you how.  So the next time a SharkNado hits you will be able to use it to boost your business.

Until next time.

Making Sense of Software as a service.

Software as a service makes sense.

Last week I spoke about how the mobile web is a growing concern for your small business.  This week, I wanted to share with you another important trend in business.  Software to the public is being offered as a service.

The software as a service or SaaS, as people say in the technology field, has been around for over fifteen years.  What has changed is the technology has caught up with the theory.  Large cloud servers and access to broadband networks make it possible to perform some powerful computing from anywhere in the world at a low cost.  What this means for you the small business person is that instead of purchasing software like a book now you will subscribe to it like a magazine.

Already, Adobe, the makers of Photoshop have adopted this model.  E₃ systems is using this model for our customers.  We do this for three reasons.  First, the customer is no longer responsible for upgrades they come free of charge with the subscription.  Next the software becomes device agnostic.  It will work on a mobile phone, tablet or PC.  Finally, the user can access the software anytime or anywhere rather than the device they install it on.

When I visit small offices, I notice plenty of old versions of software lying about.  Computers with Microsoft office have versions scattered over the last decade randomly placed on computers in the office.  One computer is deliberately on an outdated operating system because they do not know if the software installed will upgrade.  With software as a service this problem goes away.  When there is a new upgrade it is part of the machines subscribed to the service automatically reflecting the changes.  You as the user do not have to do anything.  The updates just show up on the system.

When a software vendor says something is device agnostic what that are saying is that the software will work the same way on a phone, tablet, or a PC.  It should also work on a PC or a Macintosh.  As a small or medium sized business you should not be bothered with different packages and tools depending on what device you use.  Software as a service comes to the rescue again.  E₃ systems Sully 2.0 service makes it possible to use our software on a mobile phone, tablet or PC with no additional software to buy or install.

Finally, the business world is changing and becoming a 24/7 enterprise; for a small business on the web that means that customers will call for help anytime.  In order to do business in this environment, you cannot spend your entire life in the office so you need to bring the office with you.  This is where software as a service really shines because you can access your information anywhere you have a connection to the web.  This way a customer call on a Sunday does not spoil your entire weekend because you can address your customer’s needs and get back to your family and friends.

Those are the reason we do software as a service.  We understood this trend before it became a headline and we know it will work for you.  Contact us today and find out more.

Until next time.