Call for Insights

IEEE Software prompts seasoned practitioners to share their knowledge, experience and stories

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

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 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, figures/tables count for 250 words).

A 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!