Search for a command to run...
I'm a seasoned Software Engineer with over half a decade of experience shaping the world of software development. My passion is anchored in writing code that is not just efficient, but also elegant and clean. An advocate for continuous improvement, I am forever on the hunt for the most cutting-edge developments in our dynamic industry.
No comments yet. Be the first to comment.
19th of July, Friday morning's events serve as a stark reminder of the critical importance of best practices and quality standards. CrowdStrike, a leading cybersecurity company valued at around $80B, had a huge outage because of a failed global softw...
I've genuinely tried to extract the best from SCRUM, be it trying Scrum by the book, or mixing it with a sprinkle of Kanban. It is just not proving to me that it does what it says it does... I know this topic is widely debated, and many other tech le...
Achieving operational excellence is a goal many organizations strive for. This pursuit often leads to the adoption of methodologies designed to streamline processes, boost efficiency, and enhance productivity. Among these, Continuous Delivery and LEA...
This will be fun! Let's start with something I experienced not too long ago. Imagine you're working on a crucial project with tight deadlines. You're heavily relying on an online collaboration tool. Suddenly, there's a server outage. But instead of c...
In the past few months, I've had a lot of discussions with fellow tech leaders but also friends who work in tech. All of them encounter different challenges in their daily work. However, some stuff stands out and I have this idea to create a story with a fictional character but real-world challenges.
I decided to name my character John (duhh). John works at a well-known coporate giant as a Senior Software Engineer. His department is crucial to the company's triumphs yet cursed by the underlying inefficiencies that are invisible to most.
From the outside, everything seemed perfect. The product stakeholders, sitting in their glass-walled offices, were confident that their software development processes were top-notch. They pushed for enhancements and new features with a lot of faith in the system. However, inside the engineering department, things were different.
For John and his peers, the primary challenge was not actually writing the code. They were proficient and passionate about it. The real struggle was in the labyrinth of information bottlenecks that destroyed their productivity.
1.Vague Requirements
Every new project began with vague requirements. John often found himself in a dilemma – should he always chase down the right people to clarify these ambiguities, or should he proceed based on assumptions, risking significant rework later? Both options were time-consuming and frustrating, causing delays and miscommunications.
2. Prioritizing ‘Done’
The emphasis on tracking metrics to measure progress led to an unhealthy prioritization of getting tasks marked as “done.” This often meant engineers felt pressured to cut corners to meet sprint deadlines, leading to poorly implemented features passing as complete. This false sense of productivity masked underlying quality issues and technical debt.
3. Ticket-Driven Architecture
The ticket-driven approach to development forced engineers to focus on individual tasks without considering the bigger picture. Developers were used to come up with the first assumption implementation, discouraging outside-the-box thinking and resulting in a disjointed, messy architecture that lacked scalability and coherence.
4. Poor Documentation
Documentation, or rather the lack of it, was another problem for John. The existing documentation was either outdated or incomplete, which forced engineers to dive into the codebase, hoping to decipher its mysteries. This trial-and-error approach was inefficient and often led to errors that could have been avoided with proper documentation.
5. Slow Feedback Loops
The feedback loop was painfully slow.Slow build times, sluggish test pipelines, and lengthy data loads were common. Waiting for a build to complete or tests to run felt like an eternity, significantly delaying project completion. The slow release cycles added to the misery, stretching timelines and frustrating engineers.
The absence of Continuous Integration/Continuous Deployment (CI/CD) practices and observability tools was glaring. Deployments were often a gamble – a “deploy and pray” scenario. Deploying during working hours was strictly prohibited due to the risk of disrupting operations, and Fridays were a big no-no to avoid potential weekend crises. The lack of frequent, smaller releases caused bugs and issues to pile up, making each release a huge, error-prone task.
A significant yet often overlooked challenge was the technical debt that had accumulated over the years. On the surface, feature requirements seemed straightforward, and estimating efforts appeared manageable. However, once engineers began digging into the codebase, they uncovered a universe of problems. Legacy code, quick fixes, and outdated dependencies resulted in engineers spending far more time than anticipated on seemingly simple tasks. This technical debt acted as a hidden bottleneck, causing timelines to stretch and efforts to grow beyond initial estimates.
John knew that for the engineering team to truly thrive, these bottlenecks needed to be addressed. He was advocating for better practices. He demonstrated how automated testing and deployment could save time and reduce errors, gradually winning over his colleagues. He also initiated knowledge-sharing sessions, emphasizing the importance of comprehensive documentation and thoughtful architecture.
However, despite John’s persistent efforts, the upper management remained indifferent. The relentless pressure from stakeholders to deliver quickly overshadowed the need for sustainable, long-term improvements. The lack of support from upper management and the constant push to deliver under flawed processes took a toll on John.
Despite his dedication and hard work, the environment did not change. John saw his efforts repeatedly undermined by a system more focused on immediate outputs than lasting quality. The ongoing struggle drained John’s enthusiasm and energy. Eventually, he realized that without the necessary changes from the top, his efforts were in vain.
In the end, John decided to leave the corporate giant. He sought a place where his values and dedication to best practices would be appreciated and supported. John’s departure was a loss for the company, but it was a necessary step for him to find a more fulfilling and supportive work environment.
John’s story serves as a cautionary tale about the importance of addressing fundamental issues in engineering processes. It highlights the critical need for support from upper management in fostering a culture of continuous improvement and collaboration. Without this support, even the most dedicated and talented engineers can become disheartened and seek opportunities elsewhere.
