20 problems experienced by Software Development Managers and Engineers with a poor SDLC

If you are or thinking of getting involved in Software Development Management and the Systems Development Life cycle (SDLC) take a look at the top 20 problems experienced by Software Development Managers and Software Engineers when the SDLC is managed poorly and without training. Untrained staff getting involved in making technical decisions causes the most common problems in struggling and/or failing software development and software engineering projects.

  1. No time allocated for good design and architecture
  2. Code becomes unreadable and unmaintainable
  3. Code is disorganized limiting amount of software engineers and/or changes to be active at any time.
  4. Makes full and patch releases difficult or impossible without severe downtime or refactoring of code.
  5. Lack of support for multiple streams i.e. production and new development – versioning. Lack of knowledge how versioning works. Development processes overlap into production processes.
  6. Simple configuration or system administration requires a code change not variable/parameter change.
  7. Makes change extremely difficult – not scalable or object orientated.
  8. Duplication of solutions i.e. not sharing such as application and hardware servers
  9. Lack of integration with related projects
  10. 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.
  11. Lack of necessary documentation or to much unnecessary documentation
  12. No or very little enterprise development, testing, or security standards
  13. Crunch testing – development overruns into time allocated for testing, testing reduced.
  14. Scope creep
  15. Lack of clear input and output at each step.
  16. Lack of clear ownership and accountability
  17. Constantly changing release dates – forward and backward
  18. Inability to deal with late requests
  19. Pressure from business to implement change fast. Management scheduling without understanding impact and risk
  20. Inability of IT to explain and the business to understand the intricate nature of technology projects.

All the above points can be solved by a trained Software Development Manager. Don’t manage what you don’t understand and make the same mistakes – get trained. A Software Development Manager is not just a people manager. They are also the one in the middle who resolves conflicts and maintains relationships and integrations between project managers, product owners, scrum-masters involvement with software development – both technical and people management.

That is why I coach, train, and mentor new and upcoming Software Development Managers. Don’t make the same mistakes that have been made by countless others since the inception of software development and engineering.

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

Common Problems for Software Engineers in the SDLC

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.