Posted

Project Proposal: Software Team Simulator

Background Information

Discrete-event simulation has been used to model software development dynamics for decades. DuckSim demonstrates that this kind of simulation can be pedagogically useful if it has a well-designed interactive interface: a user adjusts sliders for developer pressure, codebase quality, and bug-prioritization strategy, presses Run, and watches burndown curves and defect counts evolve in real time.

The scenarios that DuckSim makes available correspond directly to claims that appear repeatedly in software engineering textbooks and management folklore. Most programmers have encountered these claims in the abstract; few have had the opportunity to observe how sensitive outcomes are to starting conditions. An open-source, locally-installable simulator would make that experience available without a subscription.

Asimpy is a Python discrete-event simulation library that is already in use in related work in this project. It provides the process-oriented simulation primitives needed to model software teams: developers as processes, backlogs as queues, bugs as entities with arrival and service rates, and deploy pipelines as resources with finite capacity.

Mentor

Greg Wilson is an independent educator and software engineering author who has spent decades teaching software development skills and designing learning materials for developers at all stages of their careers.

Project Description

The goal of this project is to build a Python-based GUI application that runs configurable simulations of software teams using asimpy as the underlying discrete-event simulation engine. The user selects a scenario from a menu, adjusts its parameters using interactive sliders, runs the simulation, and views the results as animated line charts that update as the simulated days advance. The application must be runnable locally from the command line without a network connection.

The project will implement at minimum four scenarios, each grounded in a well-known software engineering dynamic:

Schedule Pressure models what happens when developers are pushed to go faster. Higher pressure leads to cut corners, which seeds more latent defects, which take longer to find and fix, which slows the team further. Parameters include initial system reliability, developer pressure level, and bug-prioritization strategy (interrupt, top of backlog, or bottom of backlog). Outputs include features remaining, open bug count, and system reliability score over time.

Mythical Man Month models Brooks’ Law: adding developers to a late project makes it later. The model accounts for the time new hires spend unproductive while onboarding, the coordination overhead that grows with team size, and the drag imposed by interrupting experienced developers to help newcomers. Parameters include project size, chunk size, work week hours, coordination overhead per pair, onboarding time, drag factor, and interruption rate. Output is a family of curves showing estimated project duration as a function of team size.

Staffing Strategy compares a team of configurable generalists against a reference team of highly skilled specialists. Each developer on the generalist team has adjustable skill levels across four task categories, and the user can choose whether each developer picks work from the backlog in order or seeks out work matching their highest skill. Output shows work remaining and work completed for both teams side by side over time.

Legacy Maintenance models a team adding features to an existing codebase of known quality. Parameters include developer team size, tester team size, legacy system quality, requirements quality (how accurate the information the developers are working from is), developer skill, and tester skill. Outputs include feature stories remaining, bugs found, open bugs, and total remaining work.

Project Scope

The team will select and justify a GUI framework appropriate for local desktop use in Python. The primary candidate is Marimo, which supports interactive slider widgets and live-updating charts natively and can be run as a desktop application or a local web server. Alternative candidates include Panel and Streamlit for server-style local deployment, or PyQt or Tkinter for a native desktop window. The selection must be documented and justified against concrete criteria including ease of building responsive interactive sliders, chart update performance during simulation playback, and the learning curve for contributors who will add new scenarios.

Each scenario must be implemented as a standalone asimpy simulation module with a documented parameter interface. The GUI layer must call into these modules without modification when the user presses Run; scenario modules must not import from the GUI layer. This separation of concerns is a first-class design requirement and must be enforced by the project’s test suite.

The simulation must not block the user interface thread. When the user presses Run, the simulation advances in a background thread or process, emits state snapshots at configurable intervals, and the GUI updates its charts from those snapshots without freezing. The team must choose and document a concurrency strategy, test it under the full parameter range of each scenario, and verify that it does not produce race conditions or stale chart data.

Charts must update smoothly during playback. Each scenario must display at minimum two time-series charts. Chart axes must be labeled with units, and charts must support a pause/resume control and a speed slider that adjusts the delay between simulation ticks.

The team will write unit tests for each scenario module confirming that the simulation produces qualitatively correct dynamics under well-understood parameter settings. For the Schedule Pressure scenario, for example, maximum pressure with a poor codebase must produce more total bugs and a longer completion time than minimum pressure with a clean codebase.

The project must include a short guide explaining how to add new scenarios.

Project Challenges

Model calibration is the central challenge. A simulation that produces trivially obvious outputs teaches nothing; one that produces wildly unrealistic dynamics loses credibility. Each scenario must be tuned so that its default parameter settings produce behavior that resembles what practitioners report from real projects, and so that the effect of changing each parameter is legible without a statistics degree. Achieving this requires running structured playtesting sessions with developers who can say whether a given outcome “feels right” before the team commits to the model. The team must schedule at least two calibration sessions with external reviewers and document the changes made as a result.

The concurrency design for live chart updates is technically demanding. The simplest approach, running the simulation to completion and then animating the stored results, avoids race conditions but defeats the purpose of a live simulator. Approaches that truly advance the simulation on a background thread and push updates to the GUI require careful use of thread-safe queues or async event loops. The team must prototype at least two approaches early, benchmark their responsiveness, and select one before beginning the full implementation.

The scenario abstraction boundary requires discipline. It is tempting to let scenario modules reach into the GUI for parameter values or to let the GUI call into asimpy internals rather than the documented scenario interface. Both shortcuts make the codebase harder to test and to extend. The team must establish this boundary in the first sprint and enforce it through code review throughout the project.

Finally, the project must produce something that is genuinely useful for teaching. A technically correct simulator that no instructor would assign to students is a failure. The team should identify at least one instructor willing to use the tool in a course and incorporate their feedback into the design before the final deliverable.

Number of Students

2-3 students preferred.

Sponsor-Provided Hardware and Software

No special hardware or software is required. All tools needed to complete this project are freely available as open-source software, including Python, asimpy, Marimo, and the charting libraries needed for the visualization layer. The sponsor will act as project manager, participate in weekly standups, and serve as an external calibration reviewer throughout development.

Project Search Keywords

Sponsor and Project Specific Deliverables

Proprietary Information

No aspect of this project is proprietary. The project will be developed and published openly, and team members are free to discuss all aspects of their work with potential employers or graduate programs.

Availability

The sponsor is available for weekly 30-minute video calls and is flexible on the day and time, with a preference for morning slots (Eastern Time). The sponsor responds to email within 24 hours on weekdays.