"Ready, fire, aim. Do it! Make it happen! Action counts. No one ever sat their way to success."
Tom Peters
Sometimes the exhilaration of solving a problem is so exciting and pressing that there is no design to design. You would like to see a solution now - however ugly.
In such a scenario, it will be inevitable that you will have just enough time to make cursory sketches before you plunge headlong into coding. The weight of BDD or TDD would be an impediment to innovating at the speed of light.
This is OK on one conditions: that you come back to discover the correct design before releasing for actual users. This is what refactoring is all about. I totally understand that you strike while the iron is hot; there is not enough time to get everything down pap! and you just want to roll with the punches.
However, the fatal flaw would be if such a ramshackle solution was deployed into production by which time actual users would be depending on the current functionality with an expectation that there would not be any disruption in service. Then you're screwed! There is no hope. If the system was still development then you would have the liberty to break things without notice and all your 'users' would be forgiving and ultimately blame themselves if they built on sand. Therefore, never deploy into production before a complete refactor and integrate is completed.
Once the barebones is implemented - the end-to-end version which just barely manages to get the user from begining to end - can you begin the arduous task of writing behaviour and unit tests. In fact, it will be through testing that the needs for refactoring will emerge - hence trudging down the path of emergent design.