Category: Software Development Manager

Root Cause Analysis

Posted on by Steve Padraig in People, Software Development Manager

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

You can’t have your cake and eat it

Posted on by Steve Padraig in People, Software Development Manager

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?

Posted on by Steve Padraig in People, Software Development Manager, Uncategorized

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?

Posted on by Steve Padraig in Agile, Continual Service Improvement (CSI), DSDM, ITIL and ITSM, Scrum, Service Design, Service Operations, Service Strategy, Service Transition, Software Development Manager

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

Posted on by Steve Padraig in Agile, Continual Service Improvement (CSI), DSDM, ITIL and ITSM, Scrum, Service Design, Service Operations, Service Strategy, Service Transition, Software Development Manager, Waterfall
  • 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

Common Problems for Software Engineers in the SDLC

Posted on by Steve Padraig in Agile, Continual Service Improvement (CSI), DSDM, ITIL and ITSM, Scrum, Service Design, Service Strategy, Service Transition, Software Development Manager, Waterfall

Before getting into defining a Systems Development Lifecycle (SDLC) lets look at some of the main problems experienced by Software Engineers when it is done badly.

  • No time allocated for good design and architecture
    • Code becomes unreadable and unmaintainable
    • Code is disorganised limiting amount of software engineers and/or changes to be active at any time.
    • Makes full and patch releases difficult or impossible without severe downtime or refactoring of code.
    • Simple configuration or system administration requires a code change not variable/parameter change.
    • Makes change extremely difficult – not scalable or object orientated.
      Duplication of solutions i.e. not sharing such as application and hardware servers
    • Makes releases extremely difficult i.e. No thought how to release the project – to many manual processes in a release. Releases take several hours and even days. Build an object to large to get through the door.
  • Lack of necessary documentation or to much unnecessary documentation
  • No or very little enterprise development, testing, or security standards
  • Don’t manage what you don’t understand. Non technical staff getting involved in making technical decisions causes the two most common features in struggling and/or failing technology projects:
    • Pressure from business to implement change fast. Management scheduling without understanding impact and risk
    • Inability of IT to explain and the business to understand the intricate nature of technology projects.