Agile 2018

Agile 2018
Speaking at Agile 2018

Monday, September 30, 2013

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 E3 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 E3 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.

Tuesday, September 24, 2013

Patterns in the Code

Square Pegs is round holes. Could be design patterns
I spend a great deal of time reading other peoples code.  It is part of my day job as a Scrum Master.  It is also what I do as the president of E3 systems.  It is a tedious task sometimes but I recommend it for every developer working today.  This week on the blog, I want to discuss code patterns and why they are important for any developer.

In the world of literature, there are countless critics and competing schools of literary thought.  Fortunately, the world of computer science does not have that problem.  The most important standard for software is that it works and that it meets the needs of customers.  This is changing as software becomes more complex and it has become more important to the operation of the business.  Standards cropped up thanks to this new reality and I think it has been a good thing for the industry.

Developers in many respects are like painters; they are creative, temperamental and a little crazy.  Ask two developers to write the same software with the same requirements, you will get code that is written very differently.  Multiply this by several hundred developers over three continents and you have a recipe for disaster.

Most coding standards are fairly common sense.  I personally like the standards from Microsoft regarding C#.  However, I am starting to see some troubling trends.  First, the Gang of Four, design patterns for Java are being used as a cudgel to punish self taught developers.  These design patterns have been taught in computer science classes the last ten years and the original book on the subject came out in 1994.  Today those patterns are used in numerous development languages.  A good developer with an understanding of the object oriented development doesn't need to use these patterns but some architects and a sizable minority think they should be the necessary grammar of development.

I strongly disagree with this position.  Gang of Four design patterns are a style of development not the last word on the subject.  To barrow from my friends in English and Communications theory, the Gang of Four represents a dialect of coding rather than the grammar.  Just like the formal language of a court room is different than the informal tome construction workers use on the job site.  There is a time and place for both and slavish devotion to design patterns make about as much sense as using a hammer to drive a wood screw.

Software developers often that they are artists but in the real world they are often being used like animators helping create large and complicated pieces of work with an almost infinite number of moving parts.  The Gang of Four design patterns are helpful but are being misused by a minority in the development community to judge the ability of other developers who do not understand these processes.

I am much more open to the SOLID programming approach which creates general guidelines for flexible code.  These guidelines make design patterns possible but not necessary.  If you use SOLID are more likely to write cleaner and easier to use code.  Furthermore, this approach instills good habits in both self-taught and classically trained developers.

A developer is his own worse critic.  I know that I look at code I worked on three years ago and cringe at my lack of technique.  I think I am a better developer now than I was when I started fifteen years ago.  I may not use design patterns but I think that I can create satisfying customer solutions.  In the end, that was why I wanted to be a programmer in the first place.

Until next time.

Monday, September 16, 2013

Being a Jerk Does Not Make You a Better Programmer

Can you believe this A@@ Hole.
Image courtesy of Slate.com
It has been quite a week in the technology world.  The big news this week was the firing of Business Insider’s chief technical officer Pax Dickinson for a series of insensitive and sexist tweets.  As someone who has been fired, I really do not like to gloat at the misfortune of others.  I am going to make an exception for Mr. Dickinson.  This week on the blog I explain why people like Mr. Dickinson are a poison to the profession of software development and technology start-ups.

When I first joined this profession, it was male dominated.  Guys wrote code.  It was just the nature of the profession.  Diversity was usually based on experience and ethnic background as programmers from India, Asia, and the United States blended together to form development teams.  I remember quite vividly when the attacks on the world trade center took place that the developers at my firm closed ranks around the lone Muslim member of our development team because we did not want our co-workers hassling him.  People who code together tend to stick together.

As the years wore by it became obvious to me that we needed more women in the profession.  Homosexual slurs were used to describe code that wasn't acceptable.  Developers who couldn't take a joke were called “p#%&ys” and women who worked with us affectionately referred to the development work area as the “pig pen” for all the misogynistic behavior exhibited by the developers.  It was 2009 and I had finally realized that programming had far too much alpha male ignorance associated with it.

Around this time, I discovered the Chicago area application life-cycle management group.  It was led by a woman smart as a whip and tough enough not to take any grief in the profession.  It was also here that I met many women who were managing projects and in the trenches writing code.  To me it was a revelation, women not only could write software but they could teach and provide proper instruction to their fellow developers.  It was a breath of fresh air and it was at that point I realized that if I ever started my own company I wanted to encourage the participation of women in the world of technology.

Pax Dickinson fits into this discussion because he comes from the “brogrammer” school of development.  These individuals are nurtured in the world of game development and the start-up community.  They are defined by their arrogance, intelligence and total lack of an internal filter.  They are not afraid to call an algebra teacher stupid if they know the answer before teacher shows the work on the black board.  They take pride being the smartest person in the room and will make sure everyone knows they are the smartest person in the room.  As it was explained to me once, “a good programmer is smart and he is arrogant enough to make sure everyone knows it.”

Really Mr. Dickinson fits the definition of an asshole as outlined by Robert I. Sutton PhD in his book “The No Asshole Rule” which are people,  “…who consistently aim their venom at less powerful people and rarely, if ever, at more powerful people.”  Dickinson has made a career of making people who are not him feel like dirt.  Women who he thinks can’t code are beneath him.  Developers who don’t understand his mode of operation are worthless.  Heaven forbid you question his business practices or products because that will make you a target as well.

As Mr. Dickinson gained wealth and fame in the world of technology, it merely made a bad problem worse.  Business Insider should have known better than to hire this guy but when they did they gave him the ultimate license to be an asshole to his fellow man.  It is not surprise that he got himself in trouble and soiled the reputation of the organization which fired him.

I suppose that this is an object lesion then in the world of technology.  Sooner or later an asshole is going to get what is coming to him.  They can hide but sooner or later they are exposed as the cretins they are and they are cast aside because people do not want to do business with them.  I have always striven not to be an asshole in the technology world.  It is why I founded my company and why I am looking forward to hiring developers who are going to make a difference in my organization.  I don’t care about gender, ethnic origin or religion.  I just want to make sure they know C# and can code responsive layouts.

So while Mr. Dickinson is packing his desk and protesting his punishment, I am going to get on with the business of running my start-up and helping small and medium businesses work in the cloud.

Until next time.

Monday, September 9, 2013

Business Leaders Can Learn to Code

MBA's can code it just isn't pretty.
The Harvard Business Review is always a great source of inspiration.  As a young entrepreneur, it is always nice to get wisdom from the combined academic and business community.  This week they even offered up a little bit of humor as they discussed the efforts of the MBA program to teach its students to write software.  This week, I have some thoughts about managers who try to understand technology.

Prior to entering the world of technology and seven years after earning my undergraduate degree, I decided that I wanted to earn an MBA.  I hoped it would help me advance my career and develop some financial security.  Thus began a thirteen year odyssey of fits, spurts, layoffs and late checks which culminated in me receiving my MBA.  Instead of a mortarboard during commencement I wore a Kofi hat signifying my twenty years of tribal experience as a business person.

During those thirteen years I switched careers and became a technical professional.  As I became more involved in technology, I discovered that many people who ran technology departments had no idea about what they were managing.  They people knew sales, marketing and some of them understood the company financials but rarely did they know the difference between UNIX, Linux, and Windows systems.  What made this more maddening is that they made decisions about these systems.  This gave me further incentive to get my MBA because I felt there had to be a need for business leaders who understood technology.  It is nice to see the rest of the business world is catching up with me.

The current concern about STEM careers and American’s global competitiveness has further accelerated the need for business leaders to understand code.  This is why I like the Harvard Business Review article.  They interviewed eighteen alumni of the the Harvard Business School and asked them if the CS50 class which is titled Introduction to Computer Science was worth the effort.  A whopping 83% said it was.  The class has gotten fairly popular because over the last six years over seven hundred students have taken the course.

I think the best insight that these future masters of the Universe learned is that coding is hard.  The class required two to three more work that a typical MBA elective.  Learning to write code and solve business problems requires plenty of smarts and hard work.  It is also very humbling as you make plenty of mistakes and confront long nights with little sleep and even less productivity.  Many of these students found their way into technology start-ups or IT departments.  I think this is a positive step.  Now, the MBA in the corner office will not think they are responsible for a bunch of magicians on the development staff.

It is also why I founded E3 systems.  I became tired being told by my manager to, “…just figure it out.”  I wanted a company where the boss would pitch in to help solve problems.  I also wanted a company which would help other small and medium sized businesses fix their problems.

Getting my MBA was one of the hardest things I have ever done in my life.  I say the same thing about learning to code.  Being an Entrepreneur, MBA, and a software developer is not what I envisioned when I graduated from college all those years ago but since Terri Hemmert is still doing mid-day at WXRT and Steve Stone is still broadcasting White Sox games, I can’t think of a better way to spend my life’s work.

Until next time.

Tuesday, September 3, 2013

Light Out of Darkness

We chase the dream to find light in the darkness.
The life of an entrepreneur is lonely and filled with rejection.  I spend my time alone working on products and placing the finishing touches on code.  I find myself using my free time to solicit customers and finally I am making hard business decisions which I thought I would never make.  It is a life of sacrifice which often ends in failure and only a rare few make it.  I would not trade it for anything in the world.  This week our blog post is about why E3 systems continues to chase entrepreneurial dream.

If you have been following the blog the last few weeks, you might have noticed that we have had to overcome several obstacles.  First, we decided to push back the release date of our Tony product and then the news that Microsoft was going to stop supporting their Microsoft Tag system.  Setbacks like that could kill a smaller business but I am proud to say that we are not dead yet.  We are currently looking for a new vendor for QR coding services and we will be releasing our Tony product this month.

It took personal sacrifice and hard work but I think that we are going to be in a very good position for 2014 providing three services for our customers to subscribe to.  Sully 2.0, Tony 1.0, and our continuing services make it possible for us to help the small to medium sized business achieve its goals.  We also have plans in the near future to continue development on our ever expanding line of products.

We also had a very good conversation with a local enterprise customer and hope that this will expand our exposure with business people in more rural communities.

We started this firm to chase a dream.  That dream was to help small and medium sized businesses grow and reap the benefit of cloud based computing.  If you would like to know more about us contact us here.  We think that we are close to meeting that goal.  When things are darkest is when people discover the light which will guide their way.  We have endured the darkness and we are ready to light the way.

Until next time.