That awkward talk about scaling

Portrait of a Scrum
Master as a young man.

When the signatories of the agile manifesto got together sixteen years ago, they had no idea what they created would be the basis for a reformation in the business community. I have been part of the agile movement since 2009.  I am a short timer.  During my brief agile practice, I have noticed a trend.  Software projects are getting bigger, and it is becoming increasingly difficult to lead these projects.  This week I want to talk about scaling agile as software eats the world.

When I first learned about agile and scrum, I felt like the apostle Paul on the road back from Damascus.  It was like being struck by lighting and seeing the world for the first time.  The team did work in sustainable chunks.  Stakeholders would receive rapid feedback about how the project was going.  If something was wrong, it could be escalated quickly up the chain of command.  The ability to create software would become more sane and human.

I was deeply deluded.  I did not count on the ingenuity of my fellow software developers to avoid work.  I was blind to the inertia which exists in the modern corporation which rejects new approaches to solving problems.  Finally, executives and financial professionals see agile as a threat because it undermines their need for command and control.  Confronted with these realities, agile and scrum became a means to help small teams ship software promptly.  As individual groups became successful, management began paying attention.  Soon entire Agile consulting teams sprang up offering Scrum Masters and developers who could rapidly bring software to life.  For three years, everything was going well, until enterprise software application attempted to be agile.  It was 2012 and agile hit awkward puberty.

Software teams would be sprinting at different cadences.  Some teams would be sprinting every three weeks while others would be on a two-week cycle.  Network teams were not even sprinting and would treat requests on a first in first out basis.  Finally, the marketing team would be making promises which others would have to keep.  I and others would ask, how do you scale Agile across multiple groups and projects with hundreds or thousands of developers?

The answer has fractured the agile world into three camps; scaling with scrum, SAFe, and LeSS.  I have received formal training in scaling with Scrum and SAFe.  I am looking forward to attending LeSS training in the new year.  Each camp is involved in a friendly rivalry with each other.  Each approach seems to be dealing with project scaling differently.

My first exposure to scaling agile was called, “scaling with scrum.”  The approach was very organic.  As an organization grew, the backlog of work would splinter into smaller backlogs.  These backlogs would then be delegated to teams and completed. In the end, these smaller backlogs would bubble up into a “master backlog,” so that leadership could track what was happening.  I liked it, but it did require plenty of administrative work.  It also assumed that everyone was in perfect communication with everyone else in the organization.

My next exposure to scaling came from the world of SAFe.  This framework has caught on with more prominent organizations because it has a command and control structure which is very familiar with executives.  Scrum Teams bubble up into release trains, and those trains have particular departure dates.  Networking, Software, and Hardware all obey scrum or a Kanban approach to work.  Leadership over three or four sprints then witness a “product increment” and inform what direction to take next.

I like SAFe.  It feels like a good marriage of agile and corporate structure.  I see three principle drawbacks.  First, executives can maintain a top-down approach to innovation and control of the software process.  Next, SAFe depends on quality Product Ownership, and this is the weakest area of the agile movement.  Finally, working in a SAFe development environment feels like being a cog in a giant wheel.  If we can figure out how to mitigate these issues, then SAFe might be the future of agile.

As an agile coach and scrum master, I have borrowed liberally from the scaling frameworks.  One of the tenants of the Agile Manifesto is, “…responding to change over following a plan.” So I found it necessary to incorporate elements of SAFe which work with those which can wait.  I use scaling scrum with scrum all the time in my agile practice.  I also rely on the suggestions and directions of my peers and management to get software shipped out promptly.

In my opinion, we are still in the awkward years of the Agile Reformation.  We are very good at shipping software from small teams, but when we try to scale to large multi-national corporations, we still have plenty of work to do.  Software is eating the world, and if we are not careful, it will consume agile and scrum.

Until next time.

Reputation is not licence to be a jerk

We know lots of people like this.  A few of them 
 set the conversation of the technology world.
 Image courtesy of Slate.com.

The world of technology is filled with plenty of smart, talented and colorful personalities.  This dynamic was one of the reasons why I was drawn to the business.  This week I want to talk about of these colorful personalities and how he represents some of the worst impulses in the technology business.

There are plenty of stereotypes in the technology business.  These are reinforced by popular culture in productions as diverse as James Bond movies, the Fox series 24, and the HBO program Silicon Valley.  Having over 18 years’ experience in the business, I have seen many of these stereotypes in real life.  I have also met plenty of great people who are unique and innovative in every way.

By any standard, Alex St. John should be seen as one of the leading minds in the technology field. He was self-educated and self-taught.  He created the DirectX technology which powers Xbox and just about every PC game on Windows.  His work helped make Microsoft the power house it is and he earned further accolades founding his own company.  This kind of achievement should make St. John a good will ambassador for the technology field instead, he is coming off as a colossal jerk.

I can provide numerous examples which have already been articulated elsewhere on the web.  These offenses break down into three categories.

• He does not see the value of women in technology.  Exhibit A.
• He thinks that exploitative work conditions in the software business, particularly, the game business are acceptable.  Exhibit B.
• Finally, anyone who disagrees with him is a “whiner” of not willing to work hard.  Exhibit C.

I have stated repeatedly, technology needs more women.  The fresh perspective they provide to technology is essential to improving product quality.  It also makes the office less like a Mongol raiding party and more like a 21st century work place.  The less testosterone in technology the better.

Next repeated studies have shown that long hours are a hindrance to productivity rather than a boon.  Notions of “crunch” time and working eighty hour work weeks are exploitative and boarder on the illegal practice of wage theft.  Additionally, the twelve principle of Agile discourage this mindset stressing development should sustainable.  To St. John and others developer burn-out, turnover, and alienation are the cost of doing business.  Technology workers are not different that sweatshop workers and they should be grateful for the conditions.

Finally, St. Jon has ridiculed people who disagree with him about issues of diversity and exploitation of tech workers by claiming they are not ambitious enough or smart enough to understand his arguments.  In St. John’s world, I would have died of a heart attack because I would be living on steady diet of caffeine, pizza, and stress.  The technology world has undermined two of my marriages because of high stress, turn over, and uncertain employment conditions.  It is hard to keep good employees if they don’t see or sleep with their significant others.  I consider myself a valuable professional to any organization, but to St. John, I am just a pencil to be ground down into a nub to be replaced by someone else just as disposable.

Bottom line, if you do not agree with St. John, then you are neither smart nor talented enough to work in technology.  This may explain why he is spending more time coaching CEO’s and HR professionals on how to recruit technology talent than actually managing technology talent.  I have worked for people like St. John who are convinced of their intellectual and moral superiority. It is not fun and I consider those periods the low points of my career.  Technology is changing thanks to agile and efforts to improve diversity.  Faced with the changing environment you can, lead, follow, or get out of the way.  I think that St. John is about to get trampled to death.

Until next time.

E-mail - the Enemy of a Scrum Master

E-mail can be the enemy

One of the biggest challenges for a scrum master is communications.  The scrum master is sending e-mails, attending conference calls, and walking around attempting to understand how the sprint is going and what people are saying about it.  It is not an easy job.  It requires great listening skills and the ability to communicate vital information in just about every format a modern business can throw at you.  This week I wanted to discuss e-mail because this old standby of the office is the least effective of all the tools at your disposal.

Many argue that the modern internet was born when the first e-mail was sent in 1972.  In the forty plus years since, I have seen how the technology has evolved from something helpful to the bane of a business person’s existence.  Since e-mails had a recipient and the ability to carbon copy people, the e-mail quickly became a way to disseminate information in a large organization.  Sadly, many e-mails resembled the memos which were distributed before the advent of e-mail.

E-mail as we know it today really didn’t begin until the release of two programs which changed business irrevocably.  Lotus Notes and Microsoft Outlook became the do dominant players in the e-mail game.  Notes not only featured e-mail but primitive forms which could be routed through the organization like paper forms.  Workflow as we know it was born.  Outlook was different, it was a stand-alone tool to send e-mail.  You could attach files to it and forward messages in order to keep people informed.  It was supposed to save paper and speed up collaboration.  What it did was create a vortex of time sucking busy work.  

E-mail communications quickly mirrored the dysfunctions of their parent organizations.  Organizations which were hierarchical demanded reports be forwarded up the chain of command.  This meant that the higher up in the organization you went the more e-mail you received from subordinates.  Soon upper and middle managers were swamped with e-mail.  Decisions were not faster, they took more time as decision makers waded through increasing volumes of e-mail.  E-mail also echoed the lack of trust in organizations as people sent out e-mails to inform others if something was going to go wrong and then use the mail not being read in a timely manner as an alibi.

Soon managers were having conversations similar to this in their offices,

“That sale should not have gone through.  The margin is not high enough and I have to do a major revamp of the vendor portal to make that happen,”

“I sent you an e-mail about it.  I did not hear from you so I decided to go ahead.”

…and so on.

Sometimes as a scrum master I have sent e-mail messages to senior leadership and I have gotten one word responses or the content of the mail has been misunderstood so badly that I have had to print them out hang them on the white board in my bosses office and ask what part of my writing was unclear.

E-mail does have a written record of what was said but if there is too much of it, the record is lost in the constant noise of information modern business people receive.  So e-mail is a poor tool in conveying information to others.  This is why one of the principles behind the agile manifesto is “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  Instead of sending an e-mail get up from your desk and talk to the people who make decisions.  Instead of sending an e-mail, pick up the phone and make a call.  Instead of sending an e-mail, start a video chat with the person.

I understand that executives have gotten very good at learning how to be unavailable to the “peasant masses” that work for them but as a scrum master we have to be the ones to convey information both positive and negative.  Otherwise, team success will continue to get lost in a flood of e-mail.

Until next time.

Product Owner Anti-Patterns

If your product owner behaves like this
way they are doing it wrong: very wrong!

Every scrum master needs to be on the lookout for some anti-patterns in how product owners do their jobs.  In a perfect world, the product owner and the scrum master are like siblings working toward the same goal.  The reality is that mismatched business priorities and lack of cooperation by business partners can happen in any organization.  So this article will help you recognize the smells which you should look out for as a scrum master.  I hope a few of you will be kind enough to provide some suggestions of how to deal with these anti-patterns.  Many of these examples come from Roman Pichler’s excellent book on product ownership.

The Under Powered Product Owner

We have all seen this product owner.  They have the look of an abused animal.  They are not empowered to say “no” and they when they say that they speak for the business you know what they are really saying is they speak for their boss who will overrule them when it is convenient.  The under-powered product owner is a figurehead who is their because the scrum process says so.  The people with the real say will not abdicate their authority to let this product owner do the job.  The authoring of user stories consists of being called into the boss’s office to take dictation from the boss.  Priorities are set by the boss and if something goes wrong it is the fault of the development team rather than the boss.  Everything is a priority so nothing is a priority until something goes wrong which triggers a spasm of unsustainable development. 

The Over Worked Product Owner

According to Certified Scrum Master training, each software project should have a product owner and a scrum master along with a group of developers ranging in size from five to seven people.  Executives look at this as a waste of resources and often assign multiple scrum masters over many development teams and do the same with product owners.  The by-product is the over worked product owner.  Currently, at my firm I work with a Product owner with his work divided among four software development teams.  What this does is that it forces the Product owner to only spend the minimum amount of time necessary to get stories written and to make sure that priorities are getting fit into the sprint. The stories are rewritten by the scrum master or another developer so they are clear enough to be understood by the other developers.  Stand up meetings, retrospectives, and demonstrations are missed because they are not considered critical by the product owner.  The only time they turn up is when something goes wrong or when upper management is paying attention.  Quality suffers, and the notion of sustainable development is nothing more than a sick joke.

The Absent Product Owner

Sometimes projects are kicked off and the executives who demand the work can’t find or won’t hire a product owner.  The software is still expected to get written but no one can be bothered to write the user stories.  Software developers and scrum masters should just be smart enough to find out what creates user value.  This creates situations where what is constructed is often not what the business wants. Fortunately, the failure process is faster so the executive can ask questions like “what is wrong with you people?” and “this is a simple business process why am I paying you so much money to screw this up?” 

The Product Owner by Committee

Some projects have a great deal of visibility and multiple project teams; this creates the product owner by committee.  These are individuals who are all empowered to write stories in the backlog and they are also equally empowered to set priorities.  This pulls the development like taffy and forces the scrum master and the development team to juggle priorities with dexterity of chain saws.  One mistake creates, the loss of a limb and the destruction of a career.  In addition, the horrific aftermath generates meetings which are outside the scrum process and cut into the productivity of the team.  This is why many of us in the agile community are discussing how to scale large projects because multiple development teams and product owners leads to this situation.

The Rogue Product Owner

This is a product owner who has his own personal interests in mind rather than the needs of the business when creating work for the development team.  You know when you work for a rouge product owner when your boss comes to you and asks what your team is working on.  This is because the team is making life easy for the product owner but new customers are not being generated because the features to attract those new customers are not prioritized as highly by the product owner.  This undermines the agile process because the only value being created is for the product owner instead of the business. 

So there you have it; five different anti-patterns for product owners.  Be on the watch for all of them otherwise your life as a scrum master is going to become very painful.

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.

Your Web Site Stinks We Can Help

Your website stinks.  Here is why.

The biggest challenge of software development is that users have an opinion about the subject but don’t know how to transform that opinion into something a software developer understands.  This eventually leads to gallons of coffee consumed numerous hours worked and in the end the user hates the software created because it was not what they wanted.  This week on the blog, I want to discuss what all this means for your business.

In order to do business today, any company of any size needs a web presence. In my experience, a graphic designer with some print experience is given the job and they go about creating a company brochure for the web.  Soon marketing gets involved and the sales force joins the fun.  Finally, someone in tech support chimes is saying the company does not have any infrastructure to support a web site.  In the end, the web site is an unpleasant compromise which features the branding from marketing and does not drive business to the company.

Now evolve these trends over five or ten years and you have a recipe for mediocrity and poor brand presence.  The web site is difficult to update.  The original graphic artist has left and the help desk person is behaving like a troll under a bridge because they are afraid any change will break the website.   It is a mess.
This is becoming a bigger problem because web sites are being viewed more often by mobile devices like phones and tablets.  This means you rickety web site has out of date content and looks horrible on a mobile device.

At E₃ systems we understand these challenges.  Contact us today and we will be happy to help you with responsive web design and finding a content management system that will meet your needs.

Everyone has an opinion about software and web sites.  Yours should be positive about your company web presence.

Until next time.

Science Fiction Dreams and Travel Realities

Science Fiction Dreams and Reality this week on the blog

I have been busy with trade shows and travel this week and that makes it hard to stay on top of my business and blog.  One of the interesting things about travel is that it does move you outside your comfort zone.  I also got to see the best and worst trends in technology in their natural environments.  In this blog, I want to talk about how we are living in the best of all possible worlds right now when it comes to technology.

My flight was booked via an electronic system known as SABER which has been the backbone of the airline industry since 1960.  I traveled with a mobile phone running the android operating system with the Trackit application which allowed me in real time to follow my travel plans.  I also had a tablet which used Android with three books for me to read on my flight.  Throw in my laptop and I had more computing power at my disposal than many third world countries.  This was not out of the ordinary or unusual because many of the other business travelers I journeyed with were similarly equipped.

All of the airports I traveled through had Automatic Teller Machines but no pay phones because everyone had at least one mobile device to contact someone if they needed help.  Tweets were sent, Facebook status messages were sent and deals were negotiated in terminals while people were waiting for their flights.  There were even video chats taking place via Skype.  Again none of this was out of the ordinary or unusual.  The science fiction of my 1970’s youth had come true. 

This does not mean that everything was perfect.  American Airlines canceled my flight and their customer service was spotty.  Planes were on runways without crews and it was clear that some of the flight attendants were being forced to work extra shifts to deal with the traffic.  So a two hour trip to Atlanta turned into and eight hour adventure flying to Dallas and then to Atlanta. It was an example which illustrated even the best technology cannot stand up to bad weather, institutional inertia and poor service. 

I suppose this is why Voltaire spent so much time making funof Leibniz when he said that “We live in the best of all possible worlds.”  In spite of all the modern conveniences, which we enjoy, traveling still sucks.  It is also not made any better by the dysfunctional processes we have put into place to manage travel and airport security.  This has been mockingly referred to as a “First World Problem,” because this kind of thing is merely an inconvenience and does not have life or death consequences like cholera or malnutrition. 

We are living in a technological golden age; we just take it for granted.  We can communicate with anyone via our smart phones and computers but we find it hard to communicate with the people sitting next to us on the plane.  Social stratification, government short sidedness and corporate inertia make it difficult for us to utilize the utopian dreams of all the entrepreneurs who helped inflate the dot com bubble in the 1990’s.  I wanted to become an entrepreneur because I thought I could do something anything to escape the Kafkaesque world of software consulting.  I also thought that I could help small businesses play with the big dogs and better serve customers. 

It is a grandiose thought but one that still drives me and my business.  So we do not live in a perfect technology utopia which was promised twenty years ago but when I complained about my flight being late on Twitter no one censored me.  When I made a call to my bank to deal with an overdraft I was able to compare math with the customer service rep via a mobile application.  Finally, I made dinner reservations via text message and was able to update my boss via e-mail via my tablet. 

Travel still sucks but it sucks less thanks to technology people who like me who dream big and wish to make this the best of all possible worlds.

Until next time.

Creative Destruction and Cocktails

If you don't embrace change you
will wind up like this young woman.

One of my favorite sites this time of year is the site of people on street corners dressed up as the statue of liberty, a gorilla, or some other memorable mascot attempting to try entice people to use a tax preparation service.  It is one of those subtitle rights of spring, like Groundhog Day or pitchers and catchers reporting to spring training.  I always make a point of honking my horn to recognize these people.  They are cold and I am certain that the pay is lousy but during times of economic hardship it takes a great deal of pluck and desperation to dress up and shill for a tax service.

I find these dancing mascots a welcoming relief from the constant barrage of advertisements I receive from my television and the on-line world.  They seem more personable and organic than the cool narrow casting of advertisement directly marketed to people such as myself.  This leads me to this week's blog.  Thanks to technological change these mascots are endangered and organizations that don't catch this wave of change are going to be equally extinct.  My organization is an agent of creative destruction and I want to let you know why. 

Much of my time is spent speaking with business people talking about what I do.  I tell them I write software which helps automate organizations inventory and logistics operations.  I am also working on some contact management software which will help some insurance companies stay on top of their sales force.  I am either greeted with indifference or amused curiosity.  "Why would we need that?" they ask with a tone of condescension.  I smile wryly and say that their competitors are using it and that it is going to make them more profitable.   This usually leads to a changing of the subject and someone going for an new round of drinks.  I have grown accustomed to this but it does not change the reality of the situation.  Mobile computing, cloud based computing and robotics is changing how business is being done.  Firms like mine make that possible. 

If you do not believe this statement take a look at this article from the associated press from this week.  It clearly sums up how automation, computers, and robotics are eliminating entire sections of the economy.  Here is the main take away from the article.

So machines are getting smarter and people are more comfortable using them. Those factors, combined with the financial pressures of the Great Recession, have led companies and government agencies to cut jobs the past five years, yet continue to operate just as well.

The advance of cloud computing and better automation systems are making this possible.  There are some social implications to this.  How do we deal with the surplus in labor created by automation?  Are these systems really smart or do they just follow directions better than humans? Finally, where does all the money saved go thanks to these systems?  Unfortunately, I do not have the answers to these questions.  I am going to leave that to people who are much smarter than I.   

What I can say is that my firm provides the means for businesses to get on board with these trends.  My company leverages cloud computing and the mobile web to make it possible for you to automate your systems.  We make it possible to reduce overhead and inefficiencies.  This may make some people uncomfortable but so did steam power, television dinners, and Desperate Housewives.   I am still attempting to get over my discomfort with Desperate Housewives.

So the world is getting flatter, faster, warmer, and more efficient.  We will either surf this wave of progress or drown.  I prefer surfing because I don't want to be someone standing on a corner in costume dancing to drum up business for a tax preparation service. 

Until next time. 

Why Software Development Fails.

Software development does not have to be
a train wreck.

The greatest thing about the internet is that you are exposed to the wit and wisdom of countless professionals.  When you gather together a bunch of these people we want to talk about what we do for a living.  It is just a natural extension of our identity.  Firefighters talk about firefighting, cops talk about police work, and gather together a bunch of elementary school teachers and the topic of teaching will always come up.

Last week I was exposed to a great blog article from Headspring consulting.  In it, they talk about the latest report from the Standish group.  Software developers are getting better at delivering products on time and on budget, but the success rates still resemble batting averages from baseball instead of a mature industry.  This week I want to discuss this blog and why it is so damn hard to write software. 
The present success rate for software projects is still below 50%.  This means if you are a business owner you have a less than 50% chance of a project coming in on time and on budget.   I have to agree with blog author Jeffrey Palermo, this is unacceptable.  This is why I suspect that many business owners do not want to spend money or time on software and technology because they know that the investment is risky.

I have a few theories why software is so risky.

First, software is the only technology product which is not automated.  Computer, smart phones, and mice are all manufactured on factory assembly lines.  Software is created by a bunch of engineers by hand.  This process is similar to writing a novel but it is done by committee and under often unrealistic deadlines.  This hand crafting of software means that there are no standardized parts.  So communicating with a database can be done a myriad of ways instead of one standard fashion. 

Next technology environments are heterogeneous.  It is common for a large company to have servers which run UNIX, desktop computers which run windows and staffs which have Android phones.  This means that software developers spend a great deal of time fitting square pegs into round holes.  The data on your UNIX servers needs to get on your sales forces smart phones.  It is up to your software developer to figure that out.

Third, software engineering is a craft that needs to be learned on the job.  When you hire a welder, you know that if he is hired from a union that he has spent countless hours training both in the classroom and mentored on the job.  The same holds true when you hire a plumber.  These trades have long apprenticeships where the skills to succeed on the job are taught by more skilled artisans.  Sadly, no such system exists for software engineers.  Entry level developers can be self-taught or they can be graduates from prestigious programs.  This means that no two developers are going to have the same base knowledge.

Next, there are so many different languages and design patterns for software development and no one agrees which is best.  If you want to start a fight among software developers mention that Java is a superior language to C#.  Developers are very territorial about their skills and if they are confronted with individuals who don't see design patterns and languages the same way there is going to be conflict and non-cooperation. 

Finally, many of the people who lead software teams do not have any knowledge of how software works.  If you are going into surgery you want the lead surgeon to be a doctor just like the other surgeons.  In technology, you often don't have a software engineer leading the project.  You have a manager with project management or sales experience.  This means they do not understand the challenges of the people who are actually doing the work.  It also means that they do not have the skills to help a team when it becomes "stuck" or faces unrealistic combinations of resources, time, and money. 

This is one of the reasons why I founded E₃ systems.  I wanted to do software development properly.  Since we have launched the company we have gone through two major revisions to our Sully Business Intelligence Platform.   We do an upgrade on average every three weeks and each time a potential customer has asked for a feature we have delivered it in the next release.  We are pretty proud of that record and if you would like to know more you can contact us here.

So you can take your chances developing your own software and have a less than 50% chance of success or you can hire a team that does software development the way it is supposed to be done.  I hope you give us a call. 

Until next time. 

Fighting Code Bloat

Software Bloat is not pretty so why do we have it?

I have been working as a software developer for over fourteen years.  What surprises me the most is how complicated we make software for the public.  I blame two major constituencies for this trend.  First, software developers need to stop being too clever for their own good.  We need to concentrate on doing the same features better and faster rather than cramming more features into a software program.  This desire to have software do more is affectionately known as feature bloat.  More features are crammed into the same piece of software until it gets more confusing to use. 

The other guilty party is the business people who commission these bloated software projects.  Talk to any developer and you will hear stories of reports written for only one user of a system.  You will also hear stories of features added to systems to deal with one client or situation.  Additionally, features will be added to satisfy the political needs of an organization while not making software any easier to use.  Needless to say, these situations tend to drive software developers and customers batty because these additional features represent nothing but wasted time and money from the developer.  It also represents frustration for the customer as they attempt to use the software which has grown more complicated.

This is why when we founded E₃ systems we have made a point of trying to make the software as easy to use as possible.  Life is too short to spend time in training manuals and struggling to figure out how something works.  Many businesses do not have time to train their people so it is important that software is intuitive and easy to operate.  Most people just want to write out a packing slip or print an invoice.  You shouldn’t need a degree in computer science to make that happen. 

Our Sully 2.0 system makes it easy to do Bills of Lading, Packing Slips, Invoices and purchase orders.  Drop us a line and we will be happy to show you.

Until then I suppose you are going to have to suffer with bloated software.

Until next time.