Code that explodes conventions

24 Oct 11 Customers Must Take Into Account the Advice of their Development Team

Technologically proficient customers sometimes arrogantly assume that they understand software development.  That arrogance leads customers to turn a deaf ear to the advice of the development team.  The resulting product is frequently shitty.

Software development follows a general methodology with certain steps and terminology.   The software development team understands those steps and terminology, but the customer does not.  As a result, insistence by the development on certain things must be taken seriously.  The customer does not have the knowledge that the development team has, so such insistence cannot be taken lightly.  Disagreements can exist, but the development team’s advice must at least be given heed.  In short, the customer must at least hear the development team out.

Failure to hear the development team out will most likely result in a shitty product.  Fundamental knowledge that must be heeded is held by the development team.   Failure to heed that knowledge often results in basic, avoidable errors.  While basic and highly avoided, those errors can be fatal.  The fatality is the customers product.  Often, the only barrier to avoiding a mortally wounded product is arrogance on the part of the customer.  As a result, if you want your products to do well, do not be too arrogant to take listen to advice.

Technology proficient customers often make that mistake.  They assume that understanding technology implies a knowledge of software development.  Such an implication does exist and assuming that one does often results in fatal flaws.   Consequently, I would like to implore customers to take into account the advice of their software development team.

23 Oct 11 A Sticky Issue in Software Development

Anyone who has used a computer system has run into a bad piece of software, yet few are aware as to why bad software happens.  The engineers involved are intelligent, and the project managers are as well.  The customer knows what he or she wants too.  How do all of those smart people produce a bad piece of software?

The intuitive answer is that those smart people need more knowledge and training.   Experience certainly corroborates that assessment.  Mistakes happen and some of them go unnoticed for quite a long time.  Some of those unfound mistakes result in a very bad errors.   This observation would certainly point to an engineering problem; a better process needs to be followed.

The engineering side of software has plenty of rules of thumb that are effective, however.  There are effective rules with regard to coding and naming.  These rules are known and effective.   Good testing can root out a lot of mistakes as well.  A solid testing team can root a lot of bugs.  A very good testing team with enough time can root almost any bug of significance.   As a result, a software development shop that has a good process and good engineers can produce reliably bulletproof software.  Some of the most safety and mission critical systems rely on software, and they rarely miss a beat, yet bad software still happens.

Why would a good process with good engineers still produce bad software?   The problem is not in the engineering process; rather, the difficulty lies in the requirements process.  Requirements determine what needs to be built.  If the requirements are incorrect, then the software could be hampered or even be rendered useless.  If software is missing some key piece of functionality, then it may be useless to the customer or, at best, its usefulness may be severely hampered.   As a result, requirements issues are very consequential and could be a significant source of problems.

Why do requirements issues happen?   Customers know what they want.   Generally, customers do know what they want, but small details can be very consequential.  If a software system has to interface with a particular system and it does not, then such a small oversight could make the software useless.  That’s a requirements problem and not an engineering issues.  Even if the small details have all been hashed out, what the customer wants may be different from what he or she needs.  The software may do everything that the customer asked for, but what he or she asked for may not be what he or she needs.   Consequently, requirements issues can appear even though all of the people involved are intelligent and the customer knows what he or she wants.

Knowing that requirement problems can occur, are there any solutions?   As it turns out, the solution is to turn requirements gathering into a series of conversations.  All of the parties involved talked about the project and can ask questions of each other.  These conversations iron out details and help the team zero in on what the customer needs.  The engineers can make the customer away of technical issues and customer can make the engineers away of business realities.  The best software processes collect requirements this way, and the resulting software tends to be good, so a solution does exist.

A conversation is not exactly a systematic process.   The result of the conversation depends heavily on the quality of the development team and the project management team.   If one or the other is not good at sussing out problem points or points of confusion, then the conversations will not result in getting good requirements.  Asking one question or making a single comment can radically change how the group views the project.  Good software development teams know what questions to ask and what comments to make; bad teams do not.   Consequently, the conversation process is not an absolute solution.

The result is that requirements process and not the engineering is the source of many problems in software.   This assertion sounds counterintuitive, but it remains true.  No one has been able to come up with a bulletproof, systematic way of collecting requirements.  Improvements have been made, but requirements collection remains a sticky point in software development.

07 Oct 11 An Appreciation of Steve Jobs from an Apple Skeptic

I have been deeply skeptical of Apple over the years, but in light of Mr. Jobs’ death, I will stick to aspects of Apple that I admire.

Presentation: Both the physical device and the interface of Apple’s products are beautiful.  Those aesthetics, which Apple is better at than any other company, have probably hooked their share of users.  Job’s company clearly has a tremendous eye for presentation, and they should be lauded for it.

Hype: No one publicizes products like Apple.  iPhone, iPads, Mac’s, etc. are the object of intense desire.  People will wait in lines for hours just to get one on the first day.   Every company on the planet would love to have its products be the subject of such tremendous hype, yet Apple is one of the few to achieve it.  Simply put, Jobs and his marketing people are wizards at creating hype.

Public Image: The public image of Apple and its products is crystal clean.  Apple is a wonderful company and its products are secure, reliable, and user-friendly.   What company would not want such an idyllic image?  Even an Apple skeptic like me has to marvel at the masterful way in which Jobs’ outfit controls the way that people perceive his company.

Brand Culture: Apple inspires loyalty at a cult-like level.   To outsiders, the level of loyalty displayed by hardcore Apple users could easily be the subject of cynicism, yet that loyalty should inspire awe.  How exactly did Job’s and his company manage to imbue its users with such loyalty?  Quality and functionality seem like easy answers, yet there is something more at work.   No product is so amazing as to inspire that level loyalty, so what does Apple do to inspire such loyalty? Since its inception, Apple has cultivated a culture that borders on being a cult; Apple users are intensely devoted to the product and the company.   This sort of devotion could easy be derided cynically, yet Apple deserves credit for meticulously creating and maintaining a culture that has resulted in cult-like loyalty.

Innovation: Under Jobs’ direction, Apple has had the balls to push the envelope.   No one knew that an MP3 player like the iPod would become one of the hot items of the late 20th and early 21st century, yet it did.  Job’s and Apple had the balls to take risks like that.   Such a willingness to take risks deserves to be commended, because few organizations are as willing.  Jobs’ and Apple made such risk taking routine, which is quite rare.

Although I remain a skeptic of Apple’s products, I do legitimately respect Apple with regard to the aspects described above.  Looking back at Mr. Jobs’ career, he and his acolytes should feel proud that he accomplished those things.  R.I.P, Steve.

Join thousands and get updates for free...No-Spam Guarantee