Amine Chigani and Yun Freund, GE Software
At GE, software is a horizontal capability in the company, with over 14,000 software professionals in the business. GE Software is launching the Predix™ platform, which will be a common theme across all of GE’s industries, and the company will make this platform available to the world later this year.
Eltjo Poort, CGI
Poort’s job is to review bids and projects and contribute to standardizing and improving architecture practice, based on what he finds in those reviews. In this experience report, he described experiences implementing a solution-architecting approach developed at CGI at a client’s organization.
Rebecca Wirfs-Brock, Wirfs-Brock Associates, and Joseph Yoder, The Refactory, Inc.
How do you make quality happen? Budget time for quality discussions and quality testing. During envisioning and requirements gathering, identify core qualities. The core goal of agile and lean was not just to go faster, but to get rid of waste. Quality can be a result of those processes, but you need to engineer for quality by architecting for quality and then testing for it. You’ll also need to determine appropriate times when qualities can be tested and delivered.
Ariadna Font Llitjós, IBM Watson Group; Jonathan Berger, Pivotal Labs; and Jeff Patton, Jeff Patton & Associates
Font Llitjós began this conversation-style panel with a brief review of Design Thinking 101: “Design is not a product designers produce”; “design is a process designers facilitate.” Then she introduced IBM’s method, which includes four modes of design thinking: Understand, Explore, Make/build/prototype, and Validate/iterate.
Women in Software Architecture
As part of National Women’s History Month, Pittsburgh Urban Media salutes Dr. Mary Shaw, recipient of the National Medal of Technology and Innovation in 2014. Dr. Shaw is a leader in software engineering research whose work on software architecture helped establish it as a recognized discipline, and PUM’s interview with her reveals how she got an early start in a field dominated by men and what she is most proud of today. We are pleased that Dr. Shaw will give a keynote talk at SATURN 2015, and we use this week’s link roundup to highlight other women of the software architecture discipline who will also present at SATURN 2015.
Discovering Alexander’s Properties In Your Code: In this presentation from Smalltalks 2014, Rebecca Wirfs-Brock of Wirfs-Brock Associates explains how Christopher Alexander, the building architect, inspired the first software patterns with his patterns for buildings and architecture and why she thinks his latest work could influence how you code.
Posted in Architecture-Centric Engineering, Architecture-Centric Practices, Link Roundup, SATURN Conference
Tagged agile, agile development, DevOps, SATURN 2015, SATURN Conference, software architecture, software design, software development, software engineering
Fourth International Workshop on Managing Technical Debt at ICSE 2013
San Francisco, California, May 20, 2013
Submission deadline: February 7, 2013
On May 20, 2013, we will be organizing a workshop in conjunction with the International Conference on Software Engineering (ICSE 2013) in San Francisco to scrutinize the diverse issues that are related to technical debt and the software development lifecycle. We invite practitioners and researchers to join us in discussing early findings, future directions, experiences, and results. We are seeking papers on practical experience with technical debt, and approaches to evaluate and manage technical debt. The details of the call for papers and other logistics are at our workshop site.
Posted in Architecture and Agile, Architecture-Centric Engineering, Architecture-Centric Practices, From the Trenches
Tagged agile development, agile release planning, release planning, SEI, software architecture, software design, software development, software engineering, Software Engineering Institute, technical debt
On June 5, 2012 we will be organizing a workshop co-located with the International Conference on Software Engineering (ICSE 2012) in Zurich to scrutinize the diverse issues that are related to technical debt and the software development lifecycle. The details of the call for papers and other logistics are at our workshop site. We invite practitioners and researchers to join us in discussing early findings, future directions, experiences, and results.
An initial workshop was held at the Software Engineering Institute in Pittsburgh on June 2–4, 2010. The outcomes of this workshop and open research questions are outlined in the position paper Managing Technical Debt in Software-Reliant Systems presented at the FSE/SDP 2010 Workshop on the Future of Software Engineering Research. The second workshop was held collocated with ICSE 2011. A summary of the workshop is available in the September 2011 issue of ACM SIGSOFT Software Engineering Notes.
The technical debt metaphor is gaining significant traction in the software development community, as a way to understand and communicate issues of intrinsic quality, value, and cost. The idea is that developers sometimes accept compromises in a system in one dimension (such as modularity) to meet an urgent demand in some other dimension (such as a deadline), and that such compromises incur a debt on which interest has to be paid and which should be repaid at some point for the long-term health of the project.
Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt metaphor is gaining significant traction in the software development community as a way to understand and communicate such issues. The power of the metaphor is that it communicates well the essence of the tradeoffs that are at the core of many software engineering decisions–balancing economic outcomes while continuing to meet business and user needs. The downside, however, is that the more the metaphor resonates the more there is need to understand the quantifiable and scientific principles to avoid confusion. In addition, today the metaphor is used not only to refer to suboptimal coding and refactoring practices as it was originally used by Ward Cunningham, but also to describe issues observed during different software development activities: requirements debt, testing debt, and architectural debt to name a few.