Wanted: Your Insights, Stories and Experience Reports

Do you have real-world software engineering experience to share? Maybe you have presented on it already, or blogged about it? And you would like to “upgrade” to an official publication now? Please consider a submission to the Insights column in IEEE Software.

Update (03/2023): “Migrating the Communication Protocol of Client-Server Applications” accepted for publication.

Update (8/2022): The latest installment just got published in IEEE Software Vol. 39 Issue 5: “Developing a Microservices Integration Layer for Next-Generation Rail Operations Centers” by Andrei Furda, Lionel van den Berg, Graeme Reid, Giancarlo Camera and Matteo Pinasco from Hitachi Rail in Australia.

TL;DR

IEEE Software is a bridge-building magazine, connecting professional software engineers with software researchers of all kinds to “build the community of leading software practitioners” (quoting from the homepage of the magazine). Most articles come from research, reporting study results or transfers of method and tool innovations to practice.

I am a co-editor¹ of the Insights column. Its purpose is sharing experience — road stories, things that worked (and did not work), lessons learned on large projects. So if you have done something unusual that solved a real-world problem and you think others could benefit from your solution or learnings, we can help you spread the word. And get published!

Background on IEEE Software

You’ll be in good company if you decide to publish with us. For instance, 10 of the 17 authors of the Manifesto for Agile Software Development have written for IEEE Software over the years, including Ken Beck, Alistair Cockburn and Martin Fowler. Rebecca Wirfs-Brock, who invented Responsibility-Driven Design (a predecessor of Domain-Driven Design), has written 24 articles on design. Philippe Kruchten published his 4+1 views on software architecture here.

Željko Obrenovic’s 359-degree view website is a great place to get a feel for history and content. The site has topic collections, compiles quotes, points at subscription-free content, and so on. His cover collection shows how broad the topics are (let’s sample 2016):

What Insights Offers and Looks For

Let’s look at our “from practitioners to practitioners” column now, called Insights. The magazine website positions it: “Insights is a place to write up valuable knowledge nuggets. It gives a voice to busy software professionals so that their stories are heard. This department’s goal is to share and exchange real-world experience and take a snapshot of where practical software engineering has been, is now, and is heading towards.”²

The column is supposed to cover all things software — unlike most posts in this blog, it is not limited to software architecture. Our original call for submissions can be found in Seeking Your Insights, our Department Editors’ welcome from 2014. It still is current!³

We are interested in the business and the technical context of the experience that you report, about design elements such as patterns and technologies, but also development, test and evolution practices. How did these assets do, would you use them again? This blog post suggests questions you can choose to answer, and also gives some technical writing advice.

We employ a somewhat more involved, iterative and incremental “process” than most academic journals (rationale: we target and recruit from practice, so our prospective author have very different backgrounds and resulting needs for support). It involves:

• Coaching and mentoring, e.g. about suited topics and article scoping
• Informal reviews prior to submission
• An anonymous peer review
• Professional editing support (when article has been accepted for publication)
• Ultimately, an official publication that can be cited and is listed in digital libraries such as ACM Digital Library, IEEE Xplore and DBLP.

You can submit short stories (2-3 pages) or full experience reports (up to 2800 words, with each figure or table counting as 250 words). If you are not sure yet whether your topic fits, you can also start with an abstract or outline that we will comment on. There is no hard deadline, 6 issues of the magazine come out per year, 2 to 3 of which usually have an Insights column (we used to be present in each issue, but had to cut down a bit).

An ideal submission:

1. Motivates certain software engineering challenges in a particular domain.
2. Goes into detail for selected solution elements.
3. Concludes with lessons learned that readers can relate to (and hopefully apply on their own projects).

Let’s map the theoretical advice to a concrete example of an Insights experience report:

1. The business and technical context of the featured sample project is a smart precision farming system comprising mobile apps and a cloud backend; data accuracy is a key stakeholder concern, and poor connectivity at times a real-world constraint. Mobile data synchronization was required. The article also discloses project size and duration (here: 2 years, 6 developers, etc.) so that readers get a feel for the complexity and the impact of the decision making.
2. None of the evaluated Web frameworks could handle the offline and resynchronization requirements: “the available synchronization technologies weren’t adequate”. Hence a new do-it-yourself solution for conflict resolution in the backend (without user involvement) was chosen: “unique object identifiers, revision numbers, and synchronization states of objects”. More architectural decisions and decision drivers are listed: “these decisions deal with data partitioning, prefetching, selective loading, caching, paging, and so on.”
3. We learn that one should be aware of quality requirements and tradeoffs in this technical and business context: usability and performance, security, upgradeability; maintainability vs. all others. The article concludes with a call to action: Data should find a more prominent place in architecture design methods and architect teaching; when you do something similar, plan ahead and invest time for analysis (was underestimated).⁴

Do you face offline capabilities at present? Maybe the design outlined above can help you too. Similar nuggets of advice (hopefully) appear in each issue.

More Examples of Column Content

Our column comes in three styles:

1. Experience reports (that’s where we need you, see below). For instance, “The Monolith Strikes Back: Why Istio Migrated From Microservices to a Monolithic Architecture” provides rather deep and candid rationale for the revision of a strategic architectural decision, that of architectural style and approach to decomposition (logical and/or physical). It also adds a theme of operator experience to the more familiar qualities of developer experience (of APIs) and user experience.
2. Expert interviews, for instance on Business Agility, Enterprise Integration Patterns and on Microservices (Part 1 and Part 2). Next up in this series was blockchain.⁵
3. Sometimes, if really interesting and relevant, we also accept opinion, position and direction papers, for instance on dominating software services a.k.a. siren servers. Industry conference reports also have their place.

It is hard to call out any favorites, we accepted all articles for a reason. And it is fair to say that I am still very content with, and even cherish, our collection. A second well-received experience report is “The Connected Car in the Cloud: A Platform for Prototyping Telematics Services”. Other reports point out that context is king, cover evidence-based architecting inspired by practices in medicine, and report on how to organize stepwise software retrofits (a.k.a. legacy system modernizations, when uptime matters as in the logistics domain). We were lucky enough and honored to welcome some big names and wel-published authors (just one example: “Making Sense of Agile Methods”), but also seasoned practitioners that do not write in public usually.

Let’s sample some more examples of knowledge nuggets from the collection:

• John Buck’s story of top management-workforce disconnect on the second page in “Making Companies Nimble” gives us a “buzzword test” and questions to ask when new to a client. (PDF)
• The “Software Process versus Design Quality: Tug of War?” installment reports that “software design quality is a function of the effectiveness of the followed process in a given context” and that metrics have to be chosen wisely and adjusted iteratively to get them right. (PDF)
• Noise in continuous integration (CI) builds (e.g., related to flaky tests) and managing nonfunctional service properties (e.g., service performance or stability of API contracts) are seen as real-world challenges for microservice designers according to the Jan./Feb. 2020 report on “Emerging Trends, Challenges, and Experiences in DevOps and Microservice APIs”. (PDF)

Things to be aware of

Why not simply post something on LinkedIn or your own blog? Nothing wrong with that (we do that too); but how durable will your precious output be? Once your article appears in IEEE Software, a high-profile magazine, your writing will last — it actually becomes part of the collective software engineering knowledge and will be there long after you sunset your own blog.⁶ As an entry in an official digital library, it can be be found by researchers searching the literature systematically.

Much but not all content sits behind a paywall (which is understandable from a publisher point of view, but also a challenge in times of self-publishing on the Web). If you are an IEEE member, you can subscribe to the magazine without extra charge; most universities have a campus license. It is ok to put an authors copy (i.e., the document version that got accepted) on your own webpage so that everybody can read it, not just magazine subscribers. Also, a copyright transfer form has to be signed, so management approval is often required (if you work for larger company); so start to socialize your publication plan before writing much.

Track record as a writer is not an acceptance criterion, we want to be diverse in all dimensions (level of seniority, but also location, project phase, domains, etc.); it is the experience, the story that matters (your “knowledge nuggets”). Insights is a place to establish a presence as a technical writer on a prestigious level; helping you getting published on this level is one of our job as editors (which may take some iterations, from 1-2 to more than 10!).

Contact Information

Please contact me to submit an Insights story or an experience report — perhaps, on how you applied machine learning in practice? Do not hesitate to ask if you have questions about this opportunity. My co-editor Cesare and I look forward to hearing from you!

– Olaf (ZIO), also on behalf of Cesare

Notes