Optimists or Skeptics

I got a question from one of my students taking my Software Engineering Management course about root cause analysis. They had a Software Engineering team that always produced buggy software. It had little fault tolerance and where it failed it didn’t do so gracefully. Most of it is caught by testers and returned but this is an inefficient loop. No matter how much they tried they could not get the software engineers to write less buggy code. 

We eliminated tools, process, and technology and ended up (as often as I do) that the root cause is most likley in the recruitment processs. Job descriptions and pre-screening by HR had a bias for optimists. Anyone with an ounce of skepticism rejected. 

I always advocate a balance between optimists and skeptics in any Software Engineering Team:

  • Optimists assume their code will never fail or some exceptions may never occur. They reduce testing as a result and always believe they have done enough.
  • Skeptics even with code that appears to work well assume it will not. They will capture all known exceptions and ensure whenever there is failure it is graceful. They will test extensively.

I think it is imperative that the Software Engineering Manager is involved in all stages of recruitment for their team. 

Empowering Software Engineers

One of the most difficult things for leaders to do is trust its software engineers to do what they do best – often because they don’t understand software engineering and always think the wool is being pulled over their eyes. They get a little knowledge and micro-manage.

We need to let the software engineers do what they do best. Software engineering as an art and a science. Have you ever noticed how you slow down and make mistakes when someone is looking over your shoulder? Artists make mistakes, they erase things, and begin again. Scientists make and break things, they use and refine calculations until they get perfection. That is also how software engineers work.

My course on Software Development Management will give you the Knowledge & experience to promote Teams that are:

  • self-managing
  • self-organizing

I can provide you the knowledge to be a Leader of high performing organized Software Development Teams using traditional or agile methods to:

  • trust to make decisions
  • value their opinion and expertise
  • listen more and talk less to value their expertise
  • give them breathing space to make mistakes – that is how people learn.
  • be efficient without compromising quality.
  • reduce costs through automation, reusability, & efficiency.
  • be subject matter experts in the evolutionary control of software using tools, processes, & methodology.

I teach you to understand so the wool cannot be pulled over your eyes – and your team will know that. They will value you, and you will value them. You will know how to recruit, retain, and develop the best team possible.

Hiring Software Engineers Checklist

When hiring I focus on software engineering & mindset which is 90% of the job & cannot be captured by ATS or tests. Discussion with experts will. Language & qualification are secondary. I created this guide to write my job descriptions, scan resumes, & interview to capture what the ATS cannot.

  1. Developer codes single objects. Engineers systems of multiple reusable objects.
  2. Smaller projects a jack-of-all-trades. Larger a specialist in each area.
  3. Qualification alone is no use. Real experience is. Academics can solve tests but not necessarily real problems. Experienced people solve problems but not necessarily tests.
  4. Domain specific know one industry. Others bring new ideas to the table from a variety of domains.
  5. With tools, processes, and technology zealots are fanatical & uncompromising, pragmatists are practical, evangelists seek to convert others to their ideals.
  6. Optimists assume code never fails so reduce tests. Skeptics assume code will fail and increase tests.
  7. Great engineers’ question & constructively criticize. Others do whatever is said without question.
  8. Many love to write new code – but few to debug. Fewer will debug someone else’s.

Academic v Experienced Software Engineers

A while ago, I did a root cause analysis for a Toronto client. They had problems with a software engineering team having the most trivial of tasks always missing deadlines. We found the root cause in recruitment not Software Engineering.

Job descriptions listed academic certifications as must-have. ATS found academic certification but could not convert to equivalent experience. Candidates then subjected to academic tests by HR which were assessed using a third-party. The Software Development Manager was out the loop until HR and ATS had filtered out the experienced. The team was 100% academic and needlessly over complicating solutions.

  • Academics can pass tests but have little if any experience to solve real life problems. Theoretical knowledge often is irrelevant in the workplace.
  • Experienced people have real-life experience and may find tests suited to academics harder – but in the real-world flourish.
  • Academics focus on theoretical perfection even if it doesn’t make a difference.
  • Experienced people focus on what makes a difference to the business.
  • Academics over complicate to prove a theory whereas the experienced simplify to make it economical and efficient.

The solution was the Software Development Manager scanning resume’s after the ATS and HR had their duties reduced to within their capabilities.

Root Cause Analysis

I’ve been asked to do an independent root cause analysis for a client on a software engineering project. It was a leading question as they indicated lack of testing.

In my opinion lack of testing is never the root cause but the penultimate symptom – but the sequence of events that led to a leadership decision for lack of testing is. That is normally buried in the culture and environment – the people, processes, and technology. Lack of testing was the last item to test the other items that failed.

A root cause analysis is often the beginning of a change to a culture or environment. They are often met with resistance that employee’s do not feel comfortable presenting, or feel pressured to lean one way or the other for fear of offending someone. They often default to “lack of testing” as the root cause . As an independent with no “internal politics” to deal with I am free to gather findings without prejudice.

Preventative actions are often training, mentoring, and coaching – oh and sometimes patience because technology when done right can’t be rushed.

Without doubt the two most common features that I find whilst performing a root cause analysis are not lack of testing but:

  • pressure from non-technologists to implement change to fast and scheduling change without first understanding the impact and risk
  • inability of technologists to explain and non-technologists to understand the intricate nature of Software Development Management

The (W)hole Story

A software team has dug itself into a big hole. As Software Engineering Leader I’ll throw new tools and materials of your choice into the hole. What will you do with the tools and materials?

  1. build table and chairs to make the hole more comfortable
  2. build a ladder and climb out of the hole

It’s a question I use to lead Software Engineers to make the correct conclusion unavoidable, and they arrive at that conclusion themselves. If I told them what to do there would be less buy in than trusting them to make their own decision and having complete buy in. It is difficult as a leader if you believe the wrong option is chosen but if you give the team breathing space to make a mistake they will learn.  Listen more and talk less to show you value their expertise and that maybe you will learn that they chose the right option. It’s more important to value the team’s opinion and expertise and grow together than say “I told you so.”

It’s a big ask to step back but easier when a leader has non-negotiable standards expected of software engineers that control the quality of the final output such as standards for – coding, object-orientation, testing, security, architecture etc.

It’s just one way I can help organisations with Software Development, Software Engineering, and the SDLC.

You can’t have your cake and eat it

Where are all the Software Development Managers?

Many of the Software Development Manager positions posted today in Greater Toronto Area have been posted consistently since I arrived here some 6 years ago. A similar story is told worldwide. It seems some get filled but 3 or 6 months later the same posting is back. One thing that can help fix that is proper training, mentoring, and coaching by an experienced hand.

Qualification alone is not useful unless we have real experiences is a concept widely expressed by great writers but time and time again we see qualification as the main criteria for selection. The Software Development Manager training combines your qualification with my experience. Qualification tells us someone has the knowledge to do something, experience is proof someone can do it.

You want how young and how much experience?

You want to develop new talent, Generation #, or the Millennial’s but you also want the experience of an expert with 30 years of software development management and software development life cycle (SDLC) experience. It could be that you have a “Women in Leadership”, “Women in Tech”, or “Young Person in Leadership” initiative but to get things moving now you need an expert Software Development Manager regardless of identity to train or mentor them. I’ve seen so many job advertisements asking for just these types of candidates. You can’t have your cake and eat it was my first thought and that is why I reinvented myself as a trainer, mentor, and coach after 30 years in Software Development Management. Now you can have your cake and eat it – but you will have to partner with this boomer to do it.

There is an old Irish proverb that says:-

Wisdom makes a poor man king,
a foolish man reasonable,
and a good generation of a bad one

Delivery Methods

I train, mentor, coach groups or individuals using a variety of delivery methods depending on whether you are local or in the Greater Toronto Area – face-to-face, telephone video conferences, online meetings etc. You can buy a complete course or by the hour consultancy. We can also agree for an amount of time that we I provide further support after the course is completed.

Do you need a shadow?

I can also work as a Consultant Software Development Manager, Director, or VP and work alongside you to train, coach, and mentor you into the position – as a shadow. I will work with you to accomplish everything to do with the Software Development Manager, Director, and/or VP role. Together we will lead high performing organized Software Development Teams using traditional or agile methods.

What else do I offer?

  1. Root Cause Analysis & Expert Witness
  2. Speaking and Writing Engagements
  3. Review and Audit your Software Development Management and SDLC
  4. Provide Professional Opinion and References

Who do I work with?

I can help anyone involved with Software Development Projects – not just the Software Development Manager. This is not about writing code but managing it, answering the why’s, knowing the potential problems and the solutions, how to build teams and get them working, and how to communicate between technologists and non-technologists:

  1. Executives
  2. Entrepreneurs
  3. VP’s
  4. Directors
  5. Managers
  6. Software Engineers and Developers
  7. Sales and Marketing
  8. Anyone involved with Software Development

Prepare for 2020

Get ready for 2020 and kick start you, your employee’s, and your organisations future in Software Development Management. Contact me through LinkedIn or software-development-manager.com and/or send a connection request to get latest updates and mark me for future reference.

Software engineers, programmers, developers, and data scientists – are they all the same?

Today we have many titles for what many believe is essentially one role.  They have evolved over the years into very specific roles of their own.

  1. Programmer/Developer – read and write code which is specified for them.
  2. Analyst & Programmer/Developer – programmer/developer + the ability to specify, design, and document a software component.
  3. Data Scientist – developing methods of creating, updating, reading, deleting and analyzing data. NB: Data Analysts interpret data
  4. Software Engineer – Analyst & Programmer/Developer + Data Scientist + ability to specify, design, and document a software system of multiple and reusable components. Better ability to be self-managing and high-performing team member.The engineer sees the wider picture and communicates with other team members near and far to build a system to a specification that both during and after construction does not impede other engineers, developers, and programmers.  An engineer is more object-orientated.

Pre-Y2K it would not be unusual for a single software engineer to perform all four tasks but now nearing 2020 the art of software-engineering is being sub-divided further still with fewer practicing software engineers left.  It should be stressed though that a software engineer is not a “jack of all trades and master of none” as they are quite capable of being a master of all software engineering.

Is this sub-division a good thing or a bad thing?  That all depends on the projects you aspire to be on and how transferable you wish your skills to be.

What is the definition of Success in the SDLC?

There are many software development projects that are classed as successful because they delivered on time and/or on budget and delivered the functionality requested – but survived a short while in the production environment due to their lack of scalability, and high maintenance costs due to lack of planning and foresight during the software’s initial production. These projects often require a complete rewrite, that is not successful. Every opportunity must be taken to make sure that software is written with maintenance, readability, skills availability, and scalability in mind so the software lasts for many years – future proof.

Keeping the maintenance cost down is paramount to a software project being successful; it is no use being a one hit wonder. A project must also be able to implement fixes and/or enhancements and release these speedily and in isolation to on-going development, this means having at least two separate streams of development. Firstly, there is the on-going development stream where we can create new features without impacting the ability to produce fixes. Secondly, there is a maintenance stream where we can fix any problems that arise in the production environment and release these without also releasing any work included in on-going development. Thirdly, we must make sure that fixes and enhancements made in each stream can be included in the other so one release does not overwrite fixes in the previous release.

With a good Software Development Manager and Systems Development Lifecycle (SDLC) the following will be achieved.

  • Prevent Failure
  • Have knowledge of the true state of any project
  • Enables far more accurate planning and costing
  • Better Management of expectation
  • Improved Communication
  • Less disputes
  • Better vision of what is expected
  • Better efficiency, less duplicity
  • More control – top down
  • Interoperability between projects and the business
  • Prevention of Process Creep – where one process takes authority from another

Common Problems for Leaders in the SDLC

  • Lack of support for multiple streams i.e. production and new development – versioning. Lack of knowledge how versioning works
  • Lack of integration with related projects
  • Development processes overlap into production processes and are not compatible.
  • Lack of clear input and output at each step.
  • Lack of clear ownership
  • Constantly changing release dates – forward and backward
  • Inability to deal with late requests
  • Crunch testing – development overruns into time allocated for testing, testing reduced. Can happen with many processes.
  • Management without technical expertise who override decisions made by technologists, and pressurising technologists to make change to fast