Software Engineers on their way to Pluto ... A critical look at project SDLCs
The beginning of the end ... the story begins at the end
I am a survivor. That sounds a bit like the words of a song or am I imagining that? It was a freezing cold day in outer space, at a distant location on route to Pluto located 4637.6 million kilometres from home. I first woke Team Leader, Byteonaut 906 abruptly out of his deep hibernation sleep … He knew instinctively that something was wrong. As his senses returned and he recognised the anomaly, I prepared to wake the other members of the crew. Our Team leader had started the journey together with his son 67D and close friend 305, whereby both have aged 9.5 years since they departed from their dusty launch pad in the Groot Karoo semi-desert on a hot and sunny afternoon in 2106.
The Leader battled to focus his vision, first noticing his son sleeping peacefully in his byteonaut capsule creating a huge condensation cloud with every exhalation, then the heavy condensation covering and dripping from all of the internal surfaces of the space probe. "Don't wake him," he said to me, but the process had begun and if I stopped the process, he would have died a painful death. I suppose looking back it would have been better not to waken them, but … I was … lonely and didn't want to die alone. Ironic isn't it?
The environmental control systems were struggling to counteract the outside temperatures of -235 Celsius. The slight drop in environmental temperature and rise in humidity seemed to indicate a problem … but what was wrong? Our Leader struggled to his feet and dragged himself over to the cockpit, his muscles refusing to carry his aching body in an upright posture, even with the reduced artificial gravity. He stared at the flashing red lights on the Plutonium reactor panel indicating a system overload and the impending disaster. There was no time to stop it. What he did have time to do was start the process that would eject me from the ship, which is why I am able to tell this tale.
As our intrepid leader crawled back to the crew's quarters the crew was now awake, well almost. 906 dragged himself onto the bunk bed of his son. He saluted his colleague and hugged his son one last time. They didn't have the time to understand his strange gestures, but the look on his face said something was desperately wrong. None of them, not 906, nor 67D, or their snorting colleague 305 felt the meltdown of the plutonium core, the instantaneous implosion of their exotic home and the subsequent explosion of their spacecraft. The roman god of the underworld had not allowed 622 to reach the halfway milestone … planet “Pluto.” Oh by the way, my name is Black Box CPU EDBB and I have been repeating this story and the telemetry of the last few hours, over and O-o-o…
The commanders of the other probes were woken up and alerted of the disaster by their JCN onboard controllers. They all observed the shock rings and debris of the doomed space probe with dismay.
After nine and a half years of space travel, the loss of the space probe and crew reminded everyone of the hostile environment in which they had to survive on a daily basis and the imminent arrival at the outer edge of our solar system, the Kuiper Belt, Pluto and its companion Charon.
Commander 600 glanced out of the starboard porthole and watched the approaching object with a mix of admiration and fear.
The foreword by James Pereira
Quoted from the book:
"I first learned of Willy-Peter’s idea to write this book in December 2005, when we had both just completed a mammoth, but fun, poker scalability exercise at the Microsoft MTC technology centre in Redding UK. My good friend Willy-Peter Schaub, drew me aside to tell me he was planning to write a book to illustrate and share how our real life IT projects get implemented, but using a Sci-fi theme to convey this message. On returning home, Willy shared the idea with Geoff Bruce who immediately could not let this opportunity to share his talents and experience by teaming up with Willy to write this book. This was an extremely ambitious undertaking!
As they described the book, I became intrigued. The scale of what they were planning had never been attempted before, yet the text was sorely needed. When they asked me if I would write the foreword, I immediately accepted, as my curiosity had been whetted. As they sent me each chapter to review, the significance of the book emerged. They were succeeding in their ambitious objective. So now that the book is complete, what is my opinion?
This is a brilliant book! It introduces the concepts of the IT SDLC with humour, using lessons gained in the trenches. The subject is enormously important, but before this book was written, SDLCs are usually presented using extreme “going in” positions. This made the importance of understanding all the dynamics of the various SDLC approaches difficult to communicate.
I have often discussed projects with Willy-Peter and it has been obvious that the majority of projects usually land up being developed using a healthy combination of methodologies, based on the stage that the project is in “Darwinian Natural Selection at work...”, but if at any stage we had to ask a team member if the project is using their chosen methodology, the usual answer is “no we are not using my methodology”. Usually the answer is that individuals tend to measure against “extremist or purist” conformance to their methodologies, even though the project in reality might be applying a significant portion of their chosen methodology. This can even be seen in politics where politicians usually sell their extremist views, but in reality when in power they tend to be more realistic and apply what is right for the given situation, be they Republicans or Democrats.
Software Engineering is a rigorous way of approaching any problem or problem domain. The concepts are simple, but its application can be powerful or destructive. This book shows how complex problems using enterprise architecture can be resolved by considering all the perspectives and aspects that must be addressed to understand each specific dynamic:
- Perspectives enable a dynamic to be viewed through the eyes of all of the people who need to be involved: the planner, owner, designer, builder, subcontractor, and functioning enterprise. These people and their different interests must all be understood if the result that is produced is to address their various needs.
- Aspects are the questions that must be asked to understand each problem domain. These questions are: what, how, where, who, when, and why. They need to be asked from each person's perspective.
Since the dawn of computers, many application systems have been developed at a great financial cost, yet many projects do not get to see the light of day. This is due to the complexity of the dynamics surrounding systems development. The problems are endemic. Above all, the problem is due to the inability of business and IT people to communicate effectively and measure their effectiveness of delivery towards this goal for the duration of the project.
This is not a dry technical text. In these pages, Willy-Peter and Geoff have written a book that not only informs and instructs, but also entertains! This is why I love it. Not just for the book's importance, but because it is fun to read.
James Pereira
Enterprise Architect of Barone, Budge and Dominick"
... end Quote.
For more information on the book, contact us at drpsupport@bbd.co.za and look at the blog post summarising our three exciting books.