ALTHOUGH A BIT OFF TOPIC - DOMAIN EXPERTS!
Without documentation and some kind of understandable architecture, it’s going to be a tough and sudden halt to the progress at some point. I call it the “complexity trumpet”, where there’s an exponential increase of problems as you proceed. But architecture is typically the role of a systems architect, not the programmer (architecture is a bit “philosophical”… 
).
You did well to fix it in 2 weeks!
Cleanup work can take 2 or 3 times the time it takes to create the mess.
So, ~50% code-exploring and thus proving that the core problem could actually be solved, and then another 50% development to make the solution respectable in terms of coding standards. Then the question arises:
- How much productive value does the system provide?
If the “crappy system” pays off within a week or a year matters when assessing whether if it was a good idea ar not to start out by just “making it happen”. 
I’m not arguing that without context it looks bad to have a 50/50 spending on create/cleanup. But if put into context you will often find that a guy or a girl with expert knowledge in his/her problem domain often is the only one who can actually define/explain a proper “problem definition” and its logical solution, sometimes even in the form of code.
A big problem out there is that it actually takes some very special kind of communication skills for a non-programmer to talk to a programmer and succeed in conveying the “business problems” within the domain so it can be successfully implemented as a IT tool. This is where many projects fail, probably more often than due to low technical standards.
I had taped on my desk (in my role as the systems architect) a bit of paper cut out from a computer magazine where the header of an article said “83% of IT projects fail”. And the causes of the failures seldom was due to technical incompetence, instead the systems often involved extreme technical prowess, and the systems were up running and all that, but most of the failures didn’t actually solve the problems they were set out to solve.
Or a bit broader: The users didn’t find it useful, or they found it directly hindering them in their work.
Billions and billions of dollars every year are wasted in such projects. Projects which often dies in silence and no one wants to talk about them ever after. (and if they do, they typically say “We learned a lot…” and blah, blah, blah). You get the idea.
Now this has digressed way off topic, so I leave it there, but my main point is that way too many Domain Experts (which in my previous post would be a traffic/transport planner) doesn’t dare try to hack together something to prove a point when being intimidated by IT-professionals telling them that they don’t know what they’re doing.
THE TRUE GOLD MINE
The problem is of course that neither of them typically know the other field very well, and hence the numerous failed IT-projects. So the huge and messy Grasshopper Scripts out there typically are actually a gold mine of insights put down by Domain Experts! A final polished version perfected by professional programmers is a different category of problems.
In my case I initially didn’t have any insights into the field of logistics, but I did have the luck to work tightly together with a VP of the company (the product owner), a VP which had worked his way through the company as a transport planner and finally became the economy manager & VP, and thus knew the problem/business domain by heart, combined with the deep insights about the overall business goals and key-success factors. I was a business consultant at the company doing all the groundwork of identifying the business potential of further business development, and since at least one of us understood the other person’s “language” (business logic vs IT-potentials and limitations), the combination led to a very special business system which has stood the test of time (it’s still very much up and running, and according to one of the developers who was with us from the beginning, the backend I designed is still “essentially the same”, and the system gains more more interest in different fields where flexible logistics is needed, including either automated or flexible manual planning or both combined).
But I agree that without any form of documentation, at least explaining the core concepts, a big complex system can (become “immutable” and thus) end up being a road block for the business development as the world changes.
But being off topic, I’ll leave it here.
//Rolf
[edit: spelling & clarifications]
