I should be sleeping, or maybe working, but my wonderful neighbors woke me up by making my apartment stink like cigarette smoke again tonight, and I have developed a lovely headache waiting for it to go away. So in the interim, I read some blogs.
Apparently,
Bertrand Meyer saysdirect assignment of object fields, completely messes up the architecture. So it's a small problem that becomes a huge one.
The problem is small in the sense that fixing it is very easy in the source. You just prohibit, as in Eiffel, any direct access to fields and require that these things be encapsulated in simple procedures that perform the job-procedures which, of course, may then have contracts. So it's really a problem that is quite easy to kill in the bud.
I think that this passage points out an ironic flaw in the way programmers - in particular language and framework designers - perceive programming. The general form of this thinking is: we have problem X, which is indicated (let's say) by the proliferation of direct attribute assignments. So we say, okay, we know how to handle these kinds of problems in code: we just declare that the symptom (direct attribute access) is illegal, it's an error condition, and so another component of the software-generation system (the programmer) will react to this event properly and stop creating the problem X.
This is consistent with the way that software is written: if we have a problem X, which is indicated by a buffer overrun - well, it's too difficult to specify all the myriad ways that problem X might actually manifest - so we fix the indication, and we prevent it from manifesting. We don't sit down and classify every bizarre way that a buffer overrun could affect a running program: there are too many different things that could happen, it's arguably not even possible to specify what problem X might be when it manifests, so we fix the rules so that the variety of problem is impossible.
I think that this may be why Guido van Rossum is such a genius - his perception is largely untainted by this misconception.
The misconception is that you can change a programmer's behavior in the same way you can change a program's behavior. In the case of the programmer, you need to look deeper. You need to look at X and figure out what it actually is. In some cases, direct attribute access is actually not a problem at all - it
can cause problems, but it doesn't necessarily. In the cases where it does cause problems, what's really going on? The programmer isn't developing a sufficiently strong encapsulation "contract" between the class and its customers. So we want to encourage the programmer to really think about that because that issue becomes more important as the problem scales up.
In this case, it turns out that while it sounds like a reasonable request to make of the programmer - devote more time to abstract design so that the interfaces will be cleaner and we can manage the project as it scales - it might not actually be possible. The programmer needs to see a working prototype of their system in order to judge how it's going to work in the end, and in order to do that they are going to need to make some sub-optimal choices about the initial abstractions they employ. They won't know which code is simply an implementation detail and which code is really externally published until they find themselves saying "Hey, I just wrote something like N yesterday, and this O looks a lot like an N, why don't I try to use that code I wrote before."
Here's where it starts to bump into a problem I've been thinking about a lot lately. I've been looking at the schedule I set out for myself towards the beginning of last week. A lot of things have happened and a lot of work has gotten done, but almost none of it has gone as planned. We've all been trying to talk about the schedule and update it as much as we can, but a lot of the discussion has either been "Hmm, this is just much harder than I thought it would be" or "I know it's taken 3 days so far but it still looks like a 1-day task." This is notwithstanding getting sick and other vaguaries which affect the rate of progress. Even when work is going ahead full steam, and even when there is nobody "in the loop" but myself, it's incredibly difficult to figure out what is going to need to be done in advance of the doing of it. It's also interesting to observe how even the level of certainty about how close the estimate is needs to be explored - there is a layer of meta-certainty there which is very difficult to express. For example, what I'm working on now, a MIME-generation API, was something that I thought would take a few minutes. Having written the inverse of this code and more than "half" of the generation step, I thought it would be completely trivial. It's not very hard, but it does turn out that it's more than a few hours of work to get done, because there were problems that I had not considered in my previous, super-simplified implementation that turn out to completely break the model I was previously working with.
The Agile Manifesto says that we should value "responding to change over following a plan". In general I tend to agree with the Agile way of thinking, but I don't quite get this one. I don't think it's wrong, really, but it's reactionary. What it's reacting against is the established convention of following an imposed plan which development and/or customer communication have shown to be incorrect. They're saying throw out the plan and keep the customer happy, don't set a schedule up front before it's clear what the priorities should really be.
I can't wholeheartedly agree, though, because I've seen the very positive effect that a plan can have on one's progress. When the plan is actually working, and it's possible to execute to it, it's very personally satisfying and fulfilling. Also, it provides a spur to keep working to achieve a goal that you (arguably) know is attainable.
It's hard to look at a plan and say that it's wrong, though, especially when one isn't really sure. When I'm looking at a 1-day task that has unexpectedly turned into a 2-day task, I hope that it will stay a 2-day task. I have a hard time understanding why things slip and what makes a programming task more or less work, despite a decade of programming experience and 5 years of desperately attempting to estimate tasks accurately before performing them.
To get back to the original point, my emotional reaction as a programmer is to reinforce the existing assertions about deadlines, in the hopes that the wetware in my brain will react to these invariants sensibly, as a component of a software system would. Just as Mr. Meyer sets forth certain assertions about typing and software contracts and assume they will have some bearing on unrelated problems.
On a small, distributed, agile, open-source team using Python, I find my personal time-management strategies reverting to the same comfortable shared hallucinations that make static typing, const correctness, and waterfall product planning all make sense.
Obviously I need to respond more directly and actively to change, to prototype my time and schedule management the same way I'd prototype a program, by trying some strategies quickly to see whether they work without investing too much effort, and when they do work carrying forward with them as far as they'll go.
The main question that I'm wrestling with at the moment is, how do I reconcile this with the slow-moving, context-heavy kind of thinking that programming requires? Each failed prototype is a big, expensive
task switch which throws nasty heisenbergian effects into scheduling. Each time I try to measure the effectiveness of the schedule, it slips some more, because by even
thinking about measuring the schedule, I'm not thinking about programming.
I think that the answer has something to do with regimentation, i.e. spending an hour, the same hour, every day thinking about planning and absolutely no time outside of that hour.
Posts
