I think it's a dangerous philosophy for professional work. You know what happens to code that works? It ships.
If you code out a solution to the problem in order to discover the problem space, I think the idea here is that you then can go back and write a better solution that accounts for all of the stuff you discovered via refactoring and whatnot. But you're not going to do that refactoring. You're going to ship it. Because it works and you don't know of any problems with it. Are there scaling problems? Probably, you haven't run into any yet. Does your solution fit whatever requirements other interested parties might have? Who knows! We didn't do any designing or thinking about the problem yet.
This depends on whether your organization benefits from getting things done, or whether it's better to do nothing than 90% of the solution. Lots of organizations build elaborate work-prevention infrastructure to make sure that nothing less than 100%, or even 110%, gets done.
> Does your solution fit whatever requirements other interested parties might have? Who knows! We didn't do any designing or thinking about the problem yet
Often people don't know what they want until you show them something, at which point they start telling you what's wrong with it. Design by "strawman".
Many heavily lauded startup businesses were built on code that barely worked and got backfilled later.
Any person who would not go back and do that necessary redesign is unfit to call themselves a craftsperson.
Any organization that would not demand you do that necessary redesign is a organization unfit for producing critical systems.
Any organization that would go even further and prevent/de-prioritize you from doing that necessary redesign is unfit to call whatever it is that they do “engineering”.
Why would you want to work at such a dystopian hellscape if you have the choice?
Note that this is only about shipping the known incomplete design to customers because it “works”.
And to get ahead of it, yes, startups selling systems held together by spit and twine are perfect examples of “unfit for critical systems”; you should not bet critical things on them until they mature.
Discovery code doesn't have to be bad code. My rule of abstractions is that I defer them until they are needed, even if I know that they will be needed in the next sprint or whatever. I'll do a much better job making a precise abstraction when faced with an existing solution and a new problem.
Even if discovery code were bad code; I'll take "bad" code 8 out 10 times if the competition is abstractions for abstractions' sake (which "good" code often is). Bad code is often simple and direct, and therefore simple to comprehend and fix. Fancy code is a game of jenga.
Also, requirements often change by the next sprint - so my well-laid plains would be moot either way.
One of things that a lot of people are NOT used to- Always writing good code, no matter what you are writing it for.
A while back I was building a writing small snippets to fix a production issue. A colleague looked over my shoulder and said you don't have to do all that, just get it done for now.
He was quite surprised when he learned that is how I always wrote code. It feels like people have different coding styles for different situations. They do tend to have a mode where they are doing it for production, and they are quite slow at it.
> You know what happens to code that works? It ships.
That's a process problem. Even professional writers have "drafts", you shouldn't be shipping first-draft code regardless. I guess maybe you are the equivalent of a 2 cent rag, and then product sucks, but we won't get into all the ways you can suck as a software org...
Programming is neither writing an article nor designing an engine, its somewhere in the middle. You can apply "discovery" or "drafting" to the professional process as much as you can apply engineering design paradigms. The formal act of writing (unit) testing provides this opportunity, I find, to take the "discovery" implementations, harness them in specific "design" requirements, and produce a polished product.
TDD had this backwards, design then develop, as if that would somehow produce fantastic designs (it doesn't, just a lot of test code). BDD (Behavior Driven Development) is better here, you aren't driven by your tests as much as your behaviors. You may discover them, but once you do you test that they continue to work correctly.
If this were the prominent mentality, some of the greatest pieces of software there are would never have existed because they would run into too many brick walls to even try.
Do you never go back and redesign things later? Can we not ship unless we have all ends neatly tied up?
This is basically waterfall and agile in a nutshell.
The extreme end of the other side of the spectrum is research and documentation to the extreme, coming up with a rigid, long development process that doesn't readily allow for any sort of iteration.
The only real question is what is the difference between a working prototype that gets thrown away and an actual MVP. You need buy in from the business up front, otherwise you won't be given the option to refactor or redo parts, you'll be told it is good enough and there are features that need shipping.
So better to do all discovery in a system/tool that has no risk of being shipped like excel, whiteboard, design document, conversation, human brain, etc?
Am I going to ship it and not address scaling, refactoring, etc? What about discovery outside a code environment forces our hand on this?
Feels a bit to me like the real issue is not where discovery takes place but that crucial discovery steps are skipped for whatever reason.
I'm stuck somewhere in or around 1 & 2 below.
1) those other systems for discovery suck at capturing behaviors of complex systems compared to working code in motion. Happy to discuss, but I'd love if this were an obvious conclusion somewhere in the neighborhood of The Map is Not The Kingdom trope
2) skipping important steps in discovery sucks no matter where it occur. I've seen this institutionalized/practiced at both ends of the philosophical spectrum. I wasn't being sarcastic or facetious (much) about the questions above.
I'd love it if someone could help me move somewhere past the above. I think I might sleep better at night.
This is mostly my experience, except that I DO know the problems.
I don’t get to define the deadlines, that’s up to someone in a department entirely unrelated to engineering. Therefore I only have time to ship fragile, barely-tested code which is built on fragile untested legacy code.
One way to protect against this is to explore in a language that your coworkers don't care about. Once the concept is proved, you can rewrite in whatever they prefer.
>You know what happens to code that works? It ships.
That depends on how you talk about where you are in the process. If you tell people it is done then why wouldn't it ship?
>If you code out a solution to the problem in order to discover the problem space,
At this point I would say I have figured out the problem but am still coding the solution. Because that is actually where I am in resolving the issue, the solution is known but the code to resolve it isn't complete.
> I think it's a dangerous philosophy for professional work. You know what happens to code that works? It ships.
It's worse than that this happens to code that appears to work.
But of course people who work on "prototypes" don't code for robustness, they code for "delivery time", then of course when you ship the prototype, the result is ugly..
If you code out a solution to the problem in order to discover the problem space, I think the idea here is that you then can go back and write a better solution that accounts for all of the stuff you discovered via refactoring and whatnot. But you're not going to do that refactoring. You're going to ship it. Because it works and you don't know of any problems with it. Are there scaling problems? Probably, you haven't run into any yet. Does your solution fit whatever requirements other interested parties might have? Who knows! We didn't do any designing or thinking about the problem yet.