When the forefathers of Agile met to write the manifesto that provides the guiding principles of Agile software development, Wikipedia was just formed, the iPod hadn’t launched, and the first versions of IntelliJ IDEA and Eclipse were in beta. The principles of Agile have not changed. More than ever, we strive to satisfy the customer through early and continuous delivery of valuable software.
Each person has their own beliefs about technical debt, but the whole discussion can be summed up in only a few words: new technical debt is good and old technical debt is bad. “If only it were that easy,” some insinuate.
The same marketing hype that surrounded “Agile” has now switched to “DevOps”; the combination of the two is one way to solve all the issues that IT organizations have been known for. This has generated the chimera of the “full stack” developer, which simply means that now a developer is expected to do it all. What else could it mean?
In the sixth part of his common sense software engineering series, blogger Steve Naidamast gives us a valuable lesson: although many technical managers avoid using Function Point Analysis, this gem is one of the primary foundations in actual software engineering for developing accurate and sustainable project timelines.
Surely you’ve heard of the term Technical Debt something you incur when you don’t invest in a clean code basis from the very start. With time, hastily pounded out code becomes more and more complex and difficult to maintain, it no longer scales, etc., such that costs escalate disproportionately.
After some experimentation, Tomas Rybing is back with another visualisation for teams using the Kanban method. He’s cut the top off of his Priority Pyramid and created The Volcano, which covers bigger teams and more products.
In Part IV of his ongoing series on common sense software engineering, blogger Steve Naidamast shares some wisdom he’s accumulated regarding agile methodologies. Newsflash for the young guns out there: what you’re doing isn’t new or revolutionary.
Spotify’s famously engineered agile practices have become the stuff of lean legend. The company is growing at a rapid rate and continues to employ its unique brand of agile methodology, which is intricately linked to its organic organisational culture.
No concept is more complex and nebulous to a software developer than the one that is suggested by the word “done”. Is there such a thing as a finish line in IT? And if so, what exact requirements should a programmer need to fulfil in order to cross it?
In the third part of his common sense software engineering series, blogger Steve Naidamast takes us through risk analysis and the techniques you’ll need to estimate risk exposure, including a handy a risk exposure calculation.
The Waterfall method is still a process worth considering – a bold statement from blogger Steve Naidamast in his second essay on common sense software engineering, where he talks us through the need for good Requirements Analysis.
Thinking of code as a beautiful work of art is a mistake. But at the same time we need to start seeing coding as a genuine skill that deserves professional recognition, says leading Software Craftsmanship advocate and JAX London speaker Sandro Mancuso.
From waterfall to DevOps, there have been a multitude of movements that have strived to drive software programming efficiency forwards. But not all have been able to liberate developers from the pressure to deliver results faster.
Is the sole purpose of Agile to help programmers work faster? Is it about being ‘agile’ in the literal sense? Or is there more to the Agile methodology, asks software architect Lewis Foti.