ITBGN

Software Development Pitfalls from a Commercial Development Perspective

Gary Campbell, CEO ITBGNSoftware Development Pitfalls

My name is Gary Campbell, Founder and CEO of the IT Business Group Network (“ITBGN”).

My corporation is a commercial software development company.  This environment is vastly different than “In-House” development.  Our infrastructure must comply to strict F1000 security standards, we must provide extreme visibility to stakeholders since we are not in-house: daily progress reporting, visibility of code drops,  staging access to view progress, task progress (% complete), deliverable recordings, etc.

My group and I have been involved in over 200 separate software products (different clients).  I have over 20 years of hard-core software development experience.  My management team has been managing software projects for a combined total of 125 years.  Our developers have over 300 years of commercial software development experience.  Believe me when I state we know the primary pitfalls of why projects go sour.

Here’s my take on what is wrong with this industry:

  1. PROBLEM #1 – Management wants to hire a developer. Below, I copied and pasted a random listing from Monster for a .NET developer offering position for $65,000 to $85,000 per year.
    1. Minimum 4 years of Experience
    2. NET (C#)
    3. JavaScript/ HTML/CSS/JSON/REST
    4. WCF/LINQ/Entity Framework
    5. Scrum or Kanban
    6. SQL Server
    7. Additional Web frameworks (Angular, React, Bootstrap, jQuery)
    8. CMS Development Experience
    9. Unity3d Development
    10. Azure Development
    11. Mobile Application Development

Here’s what wrong with the Job Post above:

The skills desired encapsulate 3 to 4 completely different careers.

SQL Server (DAL) / LINQ / Entity Framework – This is a DAL career.

JavaScript/ HTML/CSS/JSON/ Angular, React, Bootstrap – This is a UI career.

Mobile Application Development – This is a separate career, for native development, it is 3 careers (Win, iOS and Android) as all 3 require different languages, API knowledge and deployment experience.

Odd-Ducks – Kanban, Unity3d – Every job seems to have odd-duck specialties, good luck finding a person with all of the skills AND experience with odd-ducks.

No developer can possibly be competent in the above. As a matter of fact, based upon the example above, of the skills required, the developer would ACTUALLY be 70% incompetent in most.  Really?  You want to hire a person who at best, is 70% INCOMPETENT?  This is where we are today for ALMOST all job postings.  What this means is that effort estimations will be UNDER ESTIMATED by 300%.  It also means that the developer will unknowingly introduce performance and security issues.  Sure, a great developer will eventually figure it out, but it will cost you dearly.  Also, by having 1 developer code all of these layers, the code will be tightly coupled, difficult to test and debug, and you will need to tack on an additional 30% to the overall project budget for maintenance.

  1. PROBLEM #2 – The developer wants the job. They exaggerate their experience and knowledge depth.  This is normal for every job anyone has applied to.  However, employers do not expend enough effort verifying past employment, education claims nor the validity of technical certifications they state they have. And fewer perform criminal checks.  This is just plain lazy.
  2. PROBLEM #3 – Management does not have the ability to verify developer skills. Why not?  Well, the resource that previously worked for them has quit, management does not have a clue about the complexity of skills required and other than vetting the applicant’s work history and education and interviewing the applicant, they NEVER ACTUALLY assess the skill depth of the developer.  Sure, they may request Brain Bench tests, but all tests I have ever seen other than live, real time vetting by an expert can EASILY be fudged.  All the developer needs to do is setup 3 or 4 phony accounts, take the online test multiple times, then after collecting the questions and answers, and possibly with a few people assisting them, pass the tests with incredible results.  I once interviewed 50 people for a single skill set (Telerik).  29 passed the initial interview (with back ground checks, reference checks, confirmation of employment, etc), 28 failed a live, real-time exam producing nothing, only 2 actually had true experience and only 1 person was able to code a tiny test project in 2 hours compared to 45 minutes by our people.  Vetting is extremely important but most companies do not do it as they can’t do it.
  3. PROBLEM #4 – The CTO or management DOES NOT utilize a multiplication factor on estimates provided by a developer. In some 200 projects my company has been involved with, estimation breakdowns are NOT deep enough.  In our experience, if an estimate involves only 1 level of itemization (does not include UI, BL, DAL, model breakdowns of effort),  we have found that the estimate needs to be multiplied by a factor of 2.5 for medium complexity projects.  For F1000 companies, this factor must be raised to 3.5.  I once had a contract with Verizon for 4 years, working many hours every day with key Verizon managers.  They used a 7x factor.  So when a developer states a task will take 30 hours, it’s more likely 75.
  4. PROBLEM #5 – Most project managers I have worked with are incapable of knowing the EXACT status of a project, as the developers or team lead CONTINUALLY mislead the actual state of progress as they do NOT want to be berated for being behind.  However, this is NOT the fault of a project manager, it is the fault of management of NOT employing a code check-in reviewer who reviews daily check-ins and compares check-ins against the coding requirements.  Also, most project managers are not coders, so they themselves cannot actually verify the state of the code, code omissions (aka: try|catch with no error handling), empty methods, incorrect models, non-compliance to security, etc.  In my opinion, the project manager must be provided the tools to confirm project status PLUS the skills to determine status down to a code level.
  5. PROBLEM #6 – Management does not set aside time for education, and worse, management does not identify strengths or interests of a developer of where the developer should focus their education and skills. How is it possible for a developer to keep up in a rapidly moving career without knowing what’s going on in the real world?  Based upon our experience with some 200+ clients, only 1% to 2% of them allocated time and budget for skill upgrades of the developers.  This is pathetic, the costs of education is far less than the cost of moving forward with easier to consume technologies.

Software Fails

Summary:

The primary problem is under-estimating the competency required of everyone involved in a technology project.

The secondary problem is management’s inability to understand that tech stacks between layers are separate careers.

The third is that any mistake in the first two proceeding items result in costs and effort to be understated by multiples.

The fourth is that management does not wish to invest in skill upgrades.

It is no wonder that 68% to 70% of technology projects fail.  Or that every day, major organizations report that their data was exploited, hacked or their servers went down. Incompetency has been a HARD FACT for the past decade, as reported by reputable companies such KPMG and others.

ITBGN is in the “business” of software development.  We do not make these mistakes.  We have not failed on 200 projects, YET KPMG and many other reputable and unbiased surveys state that 70% of all technology projects will fail this year. Our commercial infrastructure and policies are unlike In-House.  Our promise is to deliver higher quality software faster, for less.  There is NO value in our services UNLESS we deliver our promise.  We are unlike most commercial development companies that try to emulate an in-house infrastructure.  Even without making these “novice” mistakes, projects can be challenging.  Our clients state they wished they called us first as being a trusted non-offshore Canadian company, we must LEGALLY deliver our promise of providing better software, faster, for less.  We do this everyday.