The Hello World Insistence
Entry question: How do we embark on a complex project?
Note: This is a very rough work in progress.
Background: I took part in a “Hackathon” recently, where you aim to program for nearly two days straight. This got me thinking about dealing with complexity.
The Hello-World Insistence
I’m not working on any project that does not have a working Hello World program.
It must actually run right here, right now. Not tomorrow. Not “I have the instructions for it and I can figure it out somehow”. No. It should just work right away!
Getting a Hello World program running involves non-trivial work. Most possible programs don’t work at all.
This means that I will only edit working programs.
Corollary: Get to a Hello World first. Programming comes later.
There’s the part where you try to get a Hello World working and there’s the part where you program. Don’t confuse the two.
Always have a working system
We can generalize this: Always have a working system. Even if it is the most trivial program ever, make sure it still runs. That will help you more than anything else.
There’s the part where you try to get the system working, and there’s the part where you add functionality. Don’t confuse the two.
One is about firefighting, the other is about improving.
Wait. Let’s consider the opposite. When do I get confused between the two? When do I try to add functionality and get the system working at the same time?
Well, trying to get the system working implies that the system is “not working” right now.
When I try to do both, my efforts get diffused. They neither lead to a working system nor improvement. I would be better off focussing my efforts on one thing at a time.
If the system is working smoothly, then I can add functionality easily.
Hmmm… This comes down to Kent Beck’s idea of a Refactoring Hat and a Coding Hat. You make it easier to make changes, and then you make changes.
TODO: What about Steve Yegge’s criticism of the whole idea of Refactoring and how it can be an excuse for lazy programming?
What do we want?
Easy to get it to run - Instant start.
Easy to change.
Remember, Planning is a necessary response to risk.
The Kent Beck way above actually goes along with what PG says about Rapid Prototyping. I think I just had Cached Thoughts about how awful and cultish all those XP and Agile methodologies were. Their techniques are now industry standard practices, and they have solid logic behind them.
Decouple the part that changes
Principle: Encapsulate the part that changes and decouple it from the rest of the system.
What kind of changes?
The obvious next questions: What sort of changes are you going to make? How can we make those changes easier?
Programs
Lots of things can change. That’s we have OOP, FP, etc. They try to encapsulate the part that changes and decouple it from the rest.
Test: Instant start. No firefighting.
You should be able to get in and start coding immediately.
You shouldn’t have to debug some earlier errors or comment some parts or change some configs to get it running again.
(This is a necessary condition. You need to satisfy more conditions than these.)
Counter-point: Be wary of over-simplifying reality
Life is messy. No amount of productivity systems or methodologies is going to change that.
You cannot be in control all of the time, or maybe even most of the time. And yet, that’s what all the systems aim to do - fit a complex reality into a simplified workflow that our puny brains can handle.
Show me the code
Enough of the theory. Show me a few concrete examples. Show me a lot, actually.
(I took a detour here and started thinking about why having a methodology for writing programs seems so seductive.)
Creativity is Hard
It’s hard to be creative. It’s even harder to be creative on demand. I have to generate meaningful, counter-intuitive ideas out of thin air, in the next five minutes? What am I - a magician?
By its very nature, creating is a messy process. It’s hard to predict and hard to control. You don’t order your creativity around, you wait for it to come up with something.
No wonder we try to avoid it. It’s a very vulnerable position to be in, almost like a beggar.1
(Ed: [2017-12-14 Thu]
Hypothesis: Work needed <- number of possible options you have to choose from, how long it takes to set one option, get its output from the mechanism, and understand the output (or whether you have some memory of the output).
Test: Wise people like judges or military officers – few options because there are few viable actions, memory or written precedents of past outcomes - easier.
Test: Makers like writers – lots of possible options for the next sentence, no memory of past outcomes because you’re creating something new (?), don’t know if it will work or not! So, you have to actually search the space of possible actions and try them out. Don’t know if you will find the correct answer or not.)
Corollary: If we can overcome our fear of the natural vulnerability that all creators feel, then we can reap a lot of insightful ideas.
Perhaps that was one of the main benefits of The Great 300-Word Experiment - it forced you to write everyday, discomfort be damned. So, you had more chances of catching good ideas.
Much of success in life is showing up. TODO
So, show up!
Corollary: If you’re feeling comfortable, you’re probably not being as creative as you can be.
The treasure is usually in areas you’re not looking. You’ve already mined the areas where you’re comfortable. There is a low barrier to entry there, so you’ve gone there plenty of times and extracted as much as you can. Now, if you want further gold, you need to enter uncharted territory.
Possible measure for Creativity: How much discomfort you felt through the day.
Point: Action is more uncomfortable than words. That’s why we do so little.
Control
Corollary: Ah! No wonder we have so many frameworks and methodologies and systems. We’re trying our best to feel in control when we’re not.
This is true in writing or programming or project management. These fields involve a lot of uncertainty and a corresponding amount of creativity. They also seem to be rife with advice.
The perception of control can be worth a lot (TODO), but as aspiring R-word people, we aren’t allowed to fool ourselves. We can’t tell ourselves we are in control when we’re not. We need to face reality as it is.
So, let’s admit some ground truths.
I desperately want to control my life. I desperately want to control my creative output. I desperately want to control my rate of progress.
But right now, it doesn’t seem like I can. (Doesn’t make my desire wrong.)
So what? Why can’t I keep using these comforting “productivity” techniques and methodologies?
PG Rule: Two options that seem equally worthwhile, choose the one that is more uncomfortable [TODO]
Why? Because you’re almost certainly avoiding it. It’s uncomfortable. It’s painful to accept.
Dent (or Joker?): The only sensible way to live life is without rules. [TODO]
Do I really look like a guy with a plan? … They’re schemers trying to control their little worlds. I try to show them how PATHETIC their plans to control things really are. [TODO]
I suspect that when you embrace discomfort, when you’re willing to look stupid or feel vulnerable, a lot more options open up than otherwise.
To put it in PG’s terms: very fine implementation of your initial, mistaken idea… [TODO]
You can run your precious productivity system perfectly through an half-assed model of the world (that you don’t even realize is half-assed) and feel comfortable.
Or, you can jump headlong into the pit of discomfort and emerge with far better options than you even imagined existed.
Keats - sipping tea on the shores [TODO]
If you’re not careful, your desire for control and comfort will be your undoing.
Embrace discomfort. Embrace chaos, because that is what is there right now.
It’s a mistake to say chaos is what we want, because it isn’t what we want. However, it’s a bigger mistake to say that we have control over our lives, because we don’t - that’s wishful thinking.
“I say Stop Being Perfect”
Corollary: Stop aiming for the time when you will have your life and all your projects in perfect order. It’s not going to happen.
I keep forgetting this. I was going over the techniques from Xtreme Programming and Pragmatic Programming, and boy are they seductive!
I’m not saying they’re not useful, mind you. The techniques they pioneered are now industry-standard.
However, the belief they (inadvertently) create in you is: I can stay in control of my project.
I mean, I have technique X and Y and Z (fill in the blanks - Unit Testing, TDD, Automation, whatever), I can surely kick my project’s ass now.
Don’t Rationalize
Warning: Don’t fall into the trap of rationalizing what you can’t change.
“I am not able to impose order on the universe right now, so I might as well just say that chaos is what we really want. No, seriously, it’s better than having things the way you want. Life is much more exciting this way, you see.”
No. We don’t decide what we really want based on what is available. That stays apart from any questions of feasibility. Yes, with the current state of technology, we may not be able to achieve many of our higher goals. It’s sad, yes, it is. We will try to get there someday and, in the meantime, make do with what we have.
Easier
That said, let’s not engage in pointless struggle.
Corollary: Make it easier too. Don’t struggle any more than you have to.
Yeah. Implement as many good techniques as you can, make sure they really work, enjoy.
But remember that creating stuff is really hard. Don’t expect to be fully in control just because you added a couple new techniques to your workflow.
Alain - fundamentally compromised affair [TODO]
Conclusion
This is one of the most important puzzle pieces I was missing.
I kept thinking about The Hacker Way vs Planning. And almost everything I’ve learned so far has come about in a haphazard manner - in no way planned. Pretty much every great achievement seemed to have come out of experimentation and serendipity.
And yet, the Way of Planning seemed so seductive. I kept vacillating.
Now, I think I know why it seems so seductive. It’s an escape from discomfort. Just follow the plan and you will reach your goal. No worries. No nail-biting. No staying awake in bed. In the face of so much pain and discomfort, the guarantee of certainty and control was irresistible.
No more.
Notes
Needless to say, these are my own untested hypotheses.
Even if other people believe the same thing, we still need evidence to back these beliefs.
Long-term Thinking
Corollary: Maybe periodically go through your programs and make sure they still run.
Should get easier with time (because they were all running a month ago). This is basically Long Thinking - Making each program run is the simplest way to keep your system up-to-date.
Other people’s ideas
Kent Beck has this idea of a Refactoring Hat and a Coding Hat, and he asks us to swap between the two modes, never doing both functions at the same time. You code, then you refactor your code, then you code some more, and so on.
We can think of a Fixing Hat and a Coding Hat. You fix the system and get it working, then you Code (improve your system), and so on.
Surprises
What is the conventional hypothesis? How do you differ?
Key idea: Doing both at the same time is inefficient.
Kent Beck: Make it easier to make changes, then make changes.
This should probably involve a cost-benefit tradeoff between making the change with the current system and making the system better and then making the change.
Two Hats at a project’s start: Get to Hello-World, then add function.
Why? Because it is (vastly) easier to make changes to a running program than it is to start from scratch. And the loss of morale from package-management hell or development environment setup can kill your project before it even begins.
Test: Instant start. No firefighting.
This is at any point of time.
Test: Do you have a working system?
Always have a working system.
Get the system working, then add function. Keep them separate.
Counter-point: Beware of over-simplifying reality.
Test: Which hat are you wearing right now?
Are you trying to do two things at once? Fixing the system and adding function?
It might work, but it won’t be efficient.
Resources
Joel Test
http://www.joelonsoftware.com/articles/fog0000000043.html
Pragmatic Programmer
The Art of Unix Programming, maybe
Continuous Delivery: Note the whole idea of getting a Hello World as soon as possible is subsumed under the idea of Frequent Releases - by releasing a Hello World (what they call a Walking Skeleton), you make sure you have released something that works (barely) and set up a working pipeline.
From Paul Graham’s Is it Worth Being Wise:
↩Advising people and writing are fundamentally different types of work. When people come to you with a problem and you have to figure out the right thing to do, you don’t (usually) have to invent anything. You just weigh the alternatives and try to judge which is the prudent choice. But prudence can’t tell me what sentence to write next. The search space is too big.
Someone like a judge or a military officer can in much of his work be guided by duty, but duty is no guide in making things. Makers depend on something more precarious: inspiration. And like most people who lead a precarious existence, they tend to be worried, not contented. In that respect they’re more like the small man of Confucius’s day, always one bad harvest (or ruler) away from starvation. Except instead of being at the mercy of weather and officials, they’re at the mercy of their own imagination.
comments powered by Disqus