Software / PROJECT ORIGINS
Why I started building Transportation Workbench
I wanted to spend less time recovering the context of a roadway project and more time doing the engineering. Transportation Workbench grew from that question.
One project, too many places to look
I started building Transportation Workbench because I wanted the different parts of a roadway project to feel like they belonged to the same project.
A plan set, a geometric calculation, a quantity, an estimate, a review comment, and a delivery milestone might all describe the same work. Yet moving between them can mean opening another file, finding another reference, checking a version, or trying to remember why a decision was made. The information exists. Bringing its context back into view becomes another task.
That was the question behind the project: why should moving one roadway project forward require searching through so many disconnected places? I wanted to spend less time rebuilding the project in my head and more time doing the engineering.
The calculation is only part of the work
Engineering software often starts with a well-defined calculation. Give it dimensions and assumptions, and it gives you a result. That is useful, but the result still needs a place to go. Which project does it belong to? Which plan or reference supports it? What should be checked before it becomes a quantity or an estimate?
Those questions connect the calculation to the rest of the work. A number without its units or assumptions is incomplete. A number without its project context can be difficult for someone else to pick up and use.
Transportation Workbench grew around that connection. My goal was to bring plans, engineering tools, quantities, estimates, reviews, and milestones within reach of one another, for my own work and potentially for other DOTD engineers facing the same friction.
Build around the project, then bring in the tools
The project is the organizing idea. Rather than treating every worksheet as a separate destination, the Workbench gives the source material and the engineering decisions a common setting. Roadway geometry, typical sections, guard rail calculations, and quantities become parts of a larger workflow.
That direction also explains why the project extends beyond calculators. Reviewing a source, documenting an assumption, and seeing the next milestone are different activities, but they affect one another. Keeping them nearby can make the sequence easier to follow.
This does not mean every part of that vision is finished. The Workbench is still evolving. Some areas have working tools and structured records; others need more development and validation. The overall workflow is the direction I am building toward, rather than a claim that every engineering task has already been integrated.
Keep the engineer in the decision
Putting information together creates a responsibility to distinguish what the software found from what the engineer accepted. The current local implementation treats recognized title-sheet fields as proposals. A person reviews the evidence before accepting a change into the project.
That is an important boundary for this kind of workspace. Making a suggestion easier to find should not quietly turn it into an approved fact. The source and the reasoning still matter, and the engineer still makes the call.
The same thinking applies to saved work. Project-owned calculation and quantity records should stay attached to the project they describe. A backup should be clear about what it contains and what needs to be reattached or reviewed after a restore. These are less visible parts of a software interface, but they help make it useful for engineering.
What I want the Workbench to change
The purpose comes back to the original frustration: recovering context. Can an engineer find the right source, use a relevant tool, and understand the next step without reconstructing the whole project first?
That question gives the build a practical test. A feature earns its place when it helps the work stay connected and makes the reasoning easier to recover.
Transportation Workbench is a software project shaped by transportation engineering. The motivation is practical: give the moving parts of a roadway project a more coherent place to live, so more attention can go toward the decisions that move it forward.