Components of Programming - What is the Essential Problem?

You'll note that when we're talking about programming, there's really these sort of two ideas happening. One is we're looking at what's the essential problem? What's the core thing that we're trying to do? What's the big idea? What's the real need? But then there's a whole bunch of specifics, right, and so we're trying to get both of those things that the idea of the scale, what are the opportunity, does the scale of what we're number of people when we use test fits or something to sort of check that, check the data. You know we're going through and looking at all these very very specific sets of issues in order to really sort of test out is this the right spot, is this the right idea, is this the right thing for this particular situation on this particular site.

And so we're looking at that big scale, the big idea, big concept, as well as these really specific sets of issues. So because of that the program has a tendency to sort of fall into these big categories. So you have goals that are written like goals, they're very open-ended and sort of directive in a sort of aspirational sense.

But then the data analysis should be very very specific so that you really have clear directives and understandings. There's no point in going through the data and then not saying what you want people to use from that analysis. You have to actually go through it and be directive and say, you know, this department wants to be next to that, and there should be direct communication. Something along those lines has to be said, otherwise the next group of people who are doing the designing don't know, they don't understand that.

So it has to sort of hit these sort of large scale ideas, these big conceptual ideas, as well as all this detail. And that detail is gonna sort of fall under these different phases. So we have the general phase, we have a needs phase, and then moves from needs into details. So you're kinda of moving through what's the big idea, what are the needs, i.e. how much space, what are the relationships, those kinds of things, into detail.

Okay this one is literally next to this one, but can see this other one, right, so you start getting beyond just what are the needs, and now we're actually getting you know really into the detail of how it's all gonna sort of string together. And you know you're not talking about sort of general scale, but you're saying yes we've actually tested it, and we actually understand this is gonna be 500 desks, you know that kind of thing. So you're going through this kind of in a phased way, and then you get back to that spot where you then go back to the essential problem.

And in that process we're gonna talk about issues that are function issues, how will things literally function. So I have a meeting with the administrators, where does that meeting take place? Okay is there a conference room? Is there some other kinda space? Do we do it out in the open? Do we need to have privacy? You know the sort of function of things has to be understood. It can't be that you get through the programming process and you don't really understand how that entity works or how people in this housing project are going to be living, like what's the intent of how they're gonna be living.

Because understanding that set of functionality becomes really important because it becomes a driver of the design. From that there may be sort of form aspects to things. Now I'm gonna be a little careful, I'm gonna come back to this one in a minute. Form does not in this context does not necessarily mean coming up with a design. It might mean sort of the idea of hierarchy or the thoughts of the sort of general ideas about kind of branded experience or kind of moving through a space, like what does it feel like.

Efficiency, time, you know how these things are, what can save time, what can be make things more efficient for whatever it is we're designing for. Those are all gonna be the kind of topics that will show up as these sort of detail elements that we start going through in this program form. Alright here's the big trick one, I've already mentioned it once.

We're gonna end up saying this literally five or six times as we go through this because it's so not normal for architects. When you're a designer, you sort of thing of everything as an opportunity for design. You are specifically not designing during programming. The whole point here is you're doing analysis of data and interviewing people and doing sort of ways of gathering information. And if you start designing before you've gathered all of the information, you are effectively closing your ears to hearing the information in a real way.

If you sort of have in your head and the project comes forward and let's say it's gonna be a bank on you know Main Street and Wood Street. You're like oh that's great, Main Street, wow, that'd be really great if it was all glass, and maybe it would you know have a sort of sense of transparency. Like if you're starting your thoughts that way, then when you start to talk to folks or look at the data or look at the situation, that's leading you away from glass, it's really hard to hear it or to see it because you've already said in your brain, it's gonna be glass.

So you've already started designing, and what that means is you're not really programming. So the whole point here is you're not designing, you don't get to the design until after the programming phase. There's a lot of stuff that's sort of like design. So we were just talking a second ago about the idea of kinda thinking about form, well that's kind of like design, but it's not the same thing as design.

Right, you're not actually saying here's the room, this is the material, this is the. You're saying here's an essence, here's an idea, here's a concept. Right, that they are open to interpretation still. And that's a kind of key understanding about programming. It is quite likely to show up on an exam like this in some way.

That there will be some very large scenario, you kind of get to the end of that scenario, and it's the whole point that you're supposed to have understood is well yeah, but we shouldn't be designing yet because we're not done with the program. So the next big aspect of this is when it really comes down to it, the program is actually about communication. This is a tool about how the client can tell the architect what the project is. And equally the banker now knows what the project is, and the GC can if there's a setup where they're involved early and for pricing or construction manager or somebody, they can all understand what the project is.

Like this is a tool for discussion. It is not something that sort of lives on its own, or it's not something that just goes into a file. Like the whole point is that it's a tool of discussion. So if it's not providing clear communication, then it's not being an effective tool.

So it needs to be written in such a way and drawn in such a way that it's clearly communicating all the aspects that are important for it to get across. For a great big complicated project, the program might be you know kinda of like a little book. It could be many many pages long, could have you know a table of contents and a whole series of different sections and chapters and all of that. For a smaller project, it could be you know maybe it's a page long, and it just says you know you need this many rooms, we want this kind of effect, we want to have this kind of you know impact on the community, there you go.

So the scale of it depends on the type of the project, depends on who the audience is. It may be that the owner, the client, is very conversant with the material and feels very comfortable. It may be that they are not so conversant and comfortable with the material, and so it's really about making sure that both the architect and the owner are speaking the same language.

But in many situations, this is a key contractual element, right. When you're signing a contract to do the architectural drawings for somebody, you're signing it based on the idea of what this program says. So typically contractually it's actually not the architect's role to write it, but often architects end up writing parts of it at least or helping rewrite it or something. But it's a important contractual element.

It's the thing that says, this is a big project or this is a subtle small project. It's the device that is gonna be if anything goes wrong, we're all gonna go back to to say, well did you meet the program or not? And so it has big impact, and it should be very useful for everyone. So it can't be useful if it's not a clear and well-communicated document. Part of that process is the owner should absolutely literally sign off on it, put their signature on there so that they are saying yes, this is the program, this is the contract that I want to sign with you, this is the document that tells the effect that we are looking for, the scale that we're looking for, the budget that we're looking for, the goals that we have.

Here is that document, right. If you write a program and they don't do that, then there's sort of always an opportunity that they just don't absorb it, they don't assimilate that information. And so they don't have that same sense of ownership if you will of that information.

This has to be a two way, actually more than two ways, lots of different players involved, but let's say two way street of information going back and forth, and that's the whole point. You're creating this document that is a tool for that specific communication moment.

Log in to access files