Work time and development time
Design time is when someone signs our text documents and our UML diagrams with the greeting "This is great!" Startup time is when we execute our code and it fails with a horrible crash and burn.
The advantage of a technique like TDD is that it shrinks the gap between design time and runtime to the point where they are the same thing. This means we get instant feedback on how our design actually works when converted to code, which should lead to better design and less embarrassment when our code is live. YMMV.
source to share
Are you talking about .NET applications? In this case, design time probably means something more specific - when your GUI is presented in the Visual Studio designer. This gives you a working view of your application, but it runs at design time . Many .NET controls have a DesignMode property that allows you to determine whether the control is running while viewing the design or not.
source to share
As a developer, you should strive for a perfect balance between development time (let's say this means "the time you spend developing and developing the application", although it is a little incorrect) and the execution time, which I mean "the time when the user looks at the sandboxes. hours, waiting for his important report to be shown. "
Too much emphasis on "development time" and you may run out of planned programming time, your client will break out of the contract, he will upset you, and the kittens will die. Too little and your program will suck, as they say. Remember that "delivery is a function your program must have one of them."
If they don't mean "runtime", it is "runtime" and that means something else entirely.
source to share