Wanted: Your Insights, Stories and Experience Reports

Update 2020/2021: An update to the call for submissions with examples and background information on the IEEE Software magazine and the Insights column can be found here.

Do you have practical software engineering experience that is worth exchanging? Maybe you have presented on it already, or blogged about it? And you would like to publish an article now? If so, you may want to consider a submission for the Insights department in the software engineering magazine IEEE Software.

The  official call for submissions can be found in Seeking Your Insights, our Department Editors' welcome in IEEE Software Volume 32, Issue 2. All installments of the column that have already been published can be found here.

The magazine offers:

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

You can submit short insight stories (2-3 pages) or full experience reports (up to 2800 words, with each figure or table counting as 250 words).

Submissions should answer a subset of the following questions (detailed authoring guidelines and a submission template are available upon request):

Scenario Viewpoint/Project Management

1. What kind of project and system would you like to describe (e.g., fixed price/full scope contract work vs. self-funded development experiment; functional domain/industry sector, application genre, usage scenarios; green field vs. integration/extension vs. legacy system modernization)?
2. Did you use any recognized or company-internal software engineering methodology to plan/execute the project and construct the system (e.g., during analysis and design)? If so, which one (and why)? If not, why not?
3. Did the presented solution go live, and, if so, how many users and workload does it typically serve per day/week/month, during normal operations and during peaks?

Business Context/Project Inception

1. Who were the most important stakeholders (or stakeholder roles) and their key concerns (e.g. personas with stories, feature wishlists, desired quality attributes)?
2. If you had to describe the project vision and problem statement in one sentence, what would that sentence be?
3. Which elements of technical (and organizational/commercial) risk were you confronted with (or did you take), and how did you manage and mitigate these risks?

Design/Elaboration

1. Did you apply any recognized tactics and patterns from the literature and, if so, how? If not, did you come up with your own reproducible/reusable design elements?
2. What were your three most relevant architectural decisions: a) how did you know what to decide, b) how did you find and evaluate design alternatives, c) how did you select from these? d) Are you still content with these decisions, are their justifications still valid?  
3. Would you like to share any thoughts on modelling and notation (e.g. usage of Architecture Description Languages (ADLs) and Domain-Specific Languages (DSLs) – for instance, why did you model which parts of the system, or why did you decide not to apply any modelling techniques, notations, and tools?

Implementation/Construction

1. Would you consider the project to be an agile one? If so, which principles and practices did you apply and how were they received by the stakeholders?
2. Which software engineering tools and/or middleware did you use, and how did these assets help achieving the project goals within budget (analysis, design, development, test, support, etc.)?
3. How did you test that the functional and non-functional requirements were satisfied? Did you apply any additional validation (quality assurance, evaluation) activities (e.g. code reviews, test automation)?

Overall Retrospective

1. What worked well and what did not work well? Are there any "mysteries" left (i.e., things we do not know yet, open research problems)? Which lesson(s) did you learn on this project (e.g. method or pattern use, technology adoption, collaboration with open source communities)? What will you do differently next time?
2. How much and what kind of technical debt did you accumulate since the project start and how do you deal with it?
3. Which concluding thoughts would you like to share?

Please contact Olaf Zimmermann or Cesare Pautasso to submit an Insights story or an experience report or if you have questions about this opportunity. We look forward to your submissions!