Check out the pages on the left bar for information on me. The calendar on the right bar lists my upcoming engagements, meetings and conferences.
To subscribe to my posts, click on the icon//at// the top right corner.
|
||||||||||||||||||||||||||||||||||||||||
|
In June 2009, the Software Architecture Challenges in the 21st Century Workshop sponsored by IEEE Software, University of Southern California, and University of California Irvine attracted quite a bit of interest. Pekka Abrahamsson, Philippe Kruchten, and Grady Booch all addressed the role of sotware architecture and architecting in agile software development. I ended up writing an editorial based on this Kruchten and Booch’s talks for the September/October ‘09 issue of IEEE Software. The editorial is also featured in the August ‘09 edition of Computing Now. In that editorial I explore the common themes raised by Booch and Kruchten, and also touch upon where the two gurus differ. The common themes I identified are:
These themes made me reflect on my former views on the topic of how agile and architecture interact. Those views were expressed in a tongue-in-check article that I had written for Agile Times back in 2003 . The article was sarcastically titled “Let’s Scale Agile Up”. In those relatively early days of agile, I used to advocate a purist agilista approach that downplays architecture. I used to object to any attempts to scale up agile software development by augmenting it with explicit architecting. I was wrong. And I felt how wrong I was in a recent project. The project was small, but I couldn’t crack it with seat-of-the-pants, “let the design emerge” attitude. The project’s success relied on the ability of a complex core technology to solve the problem at hand. We had to nail down technical decisions at the beginning. And these decisions couldn’t be reversed easily later even though the project was small. And my client demanded to know about the main components, how they would interface with each other and be integrated with the core technology, how they would be decoupled from each other for maintainability and extensibility, and what general functionality would they provide. He wanted me to document the underlying decisions. In a nutshell, he demaned that I did some architecting. I ended up spending a week and a half on these issues, constantly soliciting clarifications from my clients on the requirements, running endless spikes to resolve technical risks pertaining to the core technology, and coming up with a general design in the process. And I am glad my client insisted, because this upfront activity paid off. It turned out that seemingly subtle aspects of the requirements had an impact on how the core technology, a hairy rule engine, would work to solve my client’s problem. Interstingly, I no longer associated all this early activity as I did back in 2003 with the “grit” between the gears: the grit that contaminates the project and brings it to a screeching halt. And that grit did not interfere with planning and running the project as a highly incremental and iterative one. Actually it turned out be a lubricant rather than a contaminant. I grew up, I suppose.
No, they are not superstars, or all-knowing super-powerful CEOs poised to control the world. Although one reader, and letter writer, thought that’s what I meant in my latest IEEE Software editorial titled “The seven traits of superprofessionals.” The letter writer states that he has been researching the reasons of “our” (or “my”?) economic crisis and states that he’s found a strong indicator of what kind of management behavior the future wants. Apparently it’s not exactly what my editorial describes (never mind my editorial was not about management behavior at all). The letter writer attaches the same connotation to the term “superprofessionalism” — which I coined to describe a set of behavioral traits that represent a sort of high-order professional conduct — as the false, shallow stardom associated with the kind of people featured in reality TV series like Supermodel, The Apprentice, or The Bachelor. (For a synopsis, the traits mentioned in the editorial are: focus on individual responsibility, acute awareness, brutal honesty, heightened sense of fairness, resilience under pressure, attention to detail in perspective, and pragmatism first). He alleges, those kinds of media programs and my article represent the last dying attempts to revive an old-economy thinking in which all-knowing individuals hold and dispense all power. He adds that my article advocates individual and central decision making at the expense of group decision making, and is counter to holistic team behavior and denies the emergence of information and collective intelligence from decentralized interactions in social networks. But the best stretch is when he puts the blame for the current economic crisis on the kind of thinking my writing encourages, like, say brutal honesty (he in particular picks on this trait, stating that it’s socially unacceptable). Oh? Interesting perspective, although it beats me completely how any of that can be inferred from my editorial. If it could, that perspective would represent a truly curious internal paradox on my part, given my links to the the agile software development community and in light of my previous column on the role of diversity in software development. But one can never underestimate the intellectual depth of those who can with great facility read the sub-sub-subtext between the lines. Honestly, can anyone detect any nuances in that writing, implanted with the idea to recreate or preserve old-world power? And me at the center of the conspiracy? Cheers
In a previous blog, I talked about five common mistakes authors make when trying to get an article accepted for publication in peer-reviewed software engineering journals, magazines, or proceedings. The full list includes ten common mistakes, as follows:
The February issue of Computing Now has a nice collection of articles on cloud computing. See http://www2.computer.org/portal/web/computingnow/0209/theme/software My IEEE Software column on the topic is also featured (Cloud Computing: Does Nirvana Hide Behind the Nebula?) …
The short answer is: yes it does. And I have some arsenal to back//up// this rather authoritative statement. Plenty of reasons can be found in the pages of The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies by University of Michigan professor Scott Page. Page makes a compelling case that diversity is useful because it enhances a group’s ability to tackle hard problems and make accurate predictions. Could software development possibly benefit from such enhancement? You bet. You don’t have to take my word for it though. Read the book. Or read my latest IEEE Software column, titled Diversity and Software Development on why that should be so. And let me know what you think…
Back in March, I gave a presentation to the IEEE Student Chapter at the Université du Québec à Montreal on publishing software engineering articles in peer-reviewed venues. In that presentation, I talked about the common sins prospective authors commit when trying to get a technical article accepted by a peer-reviewed publication. This post gives a synopsis of those sins. Continue reading Top 10 Ways to Kill a Paper Before It’s Born |
|
|||||||||||||||||||||||||||||||||||||||
|
Copyright © 2010 Things Software - All Rights Reserved |
||||||||||||||||||||||||||||||||||||||||
