Since 2008 I work in professional IT-projects. Back in my early days I had some bad programming habbits for sure. But luckily I learned alot in the past years - and I`m still learning - and nowadays I follow some valuable agile methods and DevOps ideals. This post is about some general project management and coding behavior that will help your project not becoming a “fucked-up-story”.

This is a true story from my past experiences. But to be fair: All facts and persons are anonymized.

The Project Setup
attention
Imagine the following situation: A customer pays over 100.000 EUR for a software and this particular application is far beyond simplicity. I assume that it happens quite regularly that all the features are only roughly planned beforehand for those kind of project volumes. So was this one, because only the core features are clear ... somehow.

The team contained of three major developers: one software architect, one frontend developer and a specialist for infrastructure implementations. The implementation of the entire GUI and the behavior of the tool at runtime is more or less up to team decisions during the development process. Two third of the developers didn`t knew about (or ignored) agile development methods and the crutial safety net called UnitTests.

All members had several years of experience and had successful projects in the past. But the outlined conditions turned into a fucked-up-story like from a textbook, but why?
Reasons for Failing
#1 Reason: Poor Communication

The team was very engaged at the beginning, specified a lot, discussed design patterns and so on. But they had neither a defined communication nor a way to safe their decisions. So by the time definitions became fuzzy. As the project made progress, the communication went down and decisions were made without clearance and had to be rolled back afterwards. These situations caused damage on the motivation and the acceptance of open discussions.

You can fix this by specifying your communication methods and take the advantage of digital tools.

Regular and mandatory meetings like in scrum would have saved the team to keep track on ongoing tasks. I would recommend internal and short meetings on a weekly basis. A kanban-like board is a perfect tool to describe and safe design decisions. A digital project board like included in GitLab supports everything most teams will need.

#2 Reason: Ingnore UnitTests

As I told you, two third of the team didn`t wrote UnitTests themselves to test their developments or to secure their code against negative side effects when things change. But one third of the team did, guess who! The result was a code base with only the most crutial tests. In addition, the UnitTests were ignored, when they failed. Instead of fixing the tests, only the productive code was debugged, so the confusion got perfect.

UnitTests have some important reasons for being. The following list is just my experience, so please leave a comment if you see more.
  • You test your covered code against errors, for sure, but you do it in parallel and always automatically. So a higher code coverage increases the power of automation and parallelism.
  • Isolated UnitTests make you creating a highliy modular and easy testable software architecture. So start new classes and functions together with UnitTests.
  • UnitTests show the intented usage of your code to your team members.
  • The implementation of your code in a productive system gets really straigt forward, when you have a UnitTest as a blue print.
  • Having UnitTests, prevents your productive code from getting polluted with inline "tests".
#3 Reason: No Management, no Workflow

The management of the project was not involved in daily programming tasks, so a role like a product owner was nearly missing. A defined process workflow was not existent. Don’t get me wrong, I don’t want to over engineer things, but in large projects like this a clear and defined workflow - no matter how - would be very helpful. The result was that individuals coded and released without planning and structured testing. The iterative releases where unstable and that caused mistrust on the customer side.

A minimalistic workflow could look like this. But you need an agreement how each step should be done - and with what tools. See the GitLab Workflow as a pretty advanced example that integrates well in the version control.

graph LR A[Plan] --> B[Code] B --> C[Test] C --> D[Release]
Conclusion

To sum the story up: Next to the portrayed reasons of failing, the delivery of a reliable software version got far beyond schedule and this made things worse. Knowing what is state-of-the-art in software development and ignoring these points is a guarantee to fail.

The world of software development is evolving fast. Customers change their mind constantly. Consequently, you’d better setup the important basics for management and communication workflows. Digital tools help to increase the efficiency. You should build a robust and clean architecture to be able to adapt quickly to new requirements.

Depending on the technologies and languages you use, the way of implementation differs. The called out principles stay mostly the same. For the domain of C# I provide the Sin.Net assemblies to build clean architectures quickly.

Writing this post was powered with music from Seeed - Molotov.
Have a nice day!
See also
Share this
Leave a comment