Last Updated on 21 September 2023 at 22:42
In a previous publication, I wrote about the era of the 1960s and 1970s when the hacker ethos was a period of rapid innovation and improvisation in software development. The primary focus was on creating functional software within the constraints of the available hardware and the absence of formal methodologies.
The late 1970s and early 1980s were pivotal periods in the evolution of software engineering, marked by the rise of the structured programming movement. This paradigm shift was spearheaded by computer science visionaries like Edsger W. Dijkstra and Donald Knuth. Dijkstra’s seminal letter “Go To Statement Considered Harmful,” published in 1968, was a clarion call for code clarity, a principle that would later become central to the practice of refactoring.
Dijkstra’s critique of the “goto” statement was not merely an academic exercise — it was a practical warning against a programming construct that made code difficult to understand and maintain. The “goto” statement, which allows for arbitrary jumps within a codebase, was a common feature in early programming languages like FORTRAN and COBOL. While it offered a certain level of flexibility, it also led to what is colloquially known as “spaghetti code,” a tangled mess of control flows that are hard to follow and debug.
The Structured Programming
Join Now
Economics Implications
Join Now
Critics of Structured Programming
Join Now
The structured programming movement of the late 1970s and early 1980s laid the intellectual and practical foundations for modern refactoring techniques. It shifted the focus from merely getting code to work to making it work well, emphasising readability, maintainability, and long-term sustainability.
While not without its critics and limitations, the principles of structured programming and refactoring have had a lasting impact on the field of software engineering, influencing not just how code is written but also how it is thought about.
FinTech Wealth Management expert with 30 years of successful track record, from Unicible/BCV to Odyssey and Temenos, plus hundreds of important banks across EMEA, APAC, and NAM.
► Background — from C-language code to C-suite in 30 years
• WealthSuite Triple’A Temenos TAP Plus expert
• crisis & change management
• complex multi-level project – program – portfolio management
• process architecture & governance, process optimization, BPO
• financial services software engineering FS FinTech
Career start as an innovative software engineer in startups ► to strategic advisory & turnaround for Tier1 & Tier2 Banks at senior C-level.
• T-shaped mastery of the latest key technologies, business, and operational practices in retail banking, asset management, core banking, PMS.
• Keen focus on improving productivity, client retention, and revenues through expertise in Program Management, Process Governance, and Optimized Delivery, augmented by know-how in complex issue resolution and value-driven E2E end-to-end implementations.
Temenos Practitioner accredited across WealthSuite and FrontOffice domains (FO, PM, TTI). Certified modules include Scripts & Formats, Implementation Methodology (T3TIM), Channels PM, APA Attribution, Constraint Management, Order Management, Data Security, WealthSuite Portfolio Management, and T24 Triple’A Interface. The Practitioner status anchors Didier’s capacity to operate as a Transformation Director, bridging certified product mastery with execution governance and program recovery.
Disclaimer —
The views and opinions expressed in this publication are those of the author, Didier Debbaut, and do not represent the views, positions, or policies of Temenos AG, its affiliates, clients, or partners. All information is shared in good faith and in the spirit of professional exchange, as part of an open, constructive contribution to the FinTech and WealthTech community.
Any technical references, opinions, or analyses are based solely on publicly available information and the author’s independent field expertise. They are offered for general informational and educational purposes only.
No confidential, proprietary, or non-public information related to Temenos products, clients, or business operations is disclosed or implied.
© Didier Debbaut — All rights reserved.
Learn when to choose High Availability, Fault Tolerance, or Disaster Recovery in Azure. Didier Debbaut maps costs, risks, and execution trade-offs.
Mixing #Agile with #Waterfall ? Think of it as a cake with the chocolatey structure of Waterfall and the creamy flexibility of Agile. The cherry on the cake is the best of both worlds, and this is how you can win at #software #development and #project #management.
The debate between Agile and Waterfall is not a zero-sum game. Each methodology has its merits and drawbacks, and the choice between the two is often dictated by the specific requirements and constraints of a project or program. However, for projects that demand both structure and flexibility, a hybrid approach can offer a balanced solution.
In practice, it is not about choosing between Waterfall and Agile; it’s about knowing when to use each. Structure and flexibility are complementary and not mutually exclusive. So, the next time someone tries to sell you on the “one true methodology”, remember: the most innovative solutions often come from combining the best of multiple worlds. It’s not about only waterfall or agile, but a lot of other methodologies, too.
Our latest publication explore the complex world of FinTech, focusing on the role of DevOps. Written by Didier Debbaut and Elena Debbaut, both experts in Software Wealth Management and Turnaround & Crisis Management, the piece aims to offer a comprehensive and nuanced understanding of DevOps’ strategic imperatives in the FinTech sector.
