|
Can/Do *good* software managers write code?
* Your boss, is he/she a good manager? Is (s)he a good software engineer, respected for their contributions in terms of code and ingenuuity?
* Does (s)he contribute code to the product base?
* Is it possible for a software engineering manager to contribute significantly to the software, or should (s)he spend his (/her) time managing?
* Should a good manager be expected to contribute to the code base?
You thoughts, your experiences? Thanks!
hoser
Sunday, March 21, 2004
If he's a technical manager, yes. Good managers have a clear vision for their product and unambiguous requirements for the people they manage. What activity satisfies that better than writing good high-level code that imposes the minimum number of constraints on subordinate code?
K
Sunday, March 21, 2004
Also, writing code makes it much easier to separate the hype from the useful.
On the other hand, having the commitment to contribute to the codebase might be harmful, because
a) The programmers will spot any tiny non-perfect code and mock it, and
b) It could hurt deadlines, in the very rare cases where there's an actual need for management.
Of course, it all depends on the type of project, the bossing style of the manager, and his/her relationship with the developers.
Dario Vasconcelos
Sunday, March 21, 2004
I am a manager/programmer myself. Whether I am good or not I will let my staff decide ;-) Keep in mind I only ever have one or two part time programmers under me, so I am forced to program much of the time.
K hit the spot: for me to help my guys and girls, I like writing code that sets the standard and shows them what I want.
If nothing else it gives me the satisfaction of producing something tangible in the short term (new feature, bug fix etc) whereas managing tasks and people have more subtle, and maybe less quantifyable, results.
It *is* possible to both code and manage, but the two often tug at each other. eg. often I want to code and fix bugs and other important jobs but simply don't have enough time to do it, because others rely on me to organise tasks, train, and pay them.
Should managers code? If they can afford the time then why not. I would always put the management role as a higher priority than coding, since there is likely to be a number of programmers relying only one manager.
PDF
Sunday, March 21, 2004
Do good building contractors lay bricks or cut 2x4's?
Do good firefighting team leaders get on the hose?
Do good conductors play an instrument?
The answer in every case is "no"
They *can* do it, and they may on occasion, but as a general rule, they are not to be considered part of the productivity. Their job is to stay above the whole mess so they can keep an objective view.
Philo
Philo
Sunday, March 21, 2004
Huh? A conductor that isn't a world class instrumentalist in his or her own right? Who? Which orchestra?
[Veal pondered with Daniel Barenboim beautifully playing nocturnes by Chopin in the background.]
veal
Sunday, March 21, 2004
"Do good firefighting team leaders get on the hose?"
if its necessary :)
FullNameRequired
Sunday, March 21, 2004
Philo, I think that's a bad comparison. You imply that any kind of "writing code" is akin to the lowest-level tasks involved in the final execution of your plan. However, that's simply not true.
If you're managing a technical project, you've got to know exactly what you want. For example, if I want my team to develop a Lisp interpreter for me, I could give them code as simple as:
// 'in' will contain any number of S-expressions (see rfc blah blah)
// e.g.: (+ 1 2 3 (sqrt 2))
// see http://blahblah for a list of functions that must be supported
// write 'FormatExpression', 'Eval', and 'ReadSExpr' for me
while(!in.eof()) cout << FormatExpression(Eval(ReadSExpr(in))) << endl;
That's not low-level at all. That's not AT ALL like "laying bricks" or "grabbing the hose". Although I think that an analogy to manual labor is fundamentally flawed in this case, what my example above equates to is something like the station chief telling his team to go to a particular address and put a fire out. That's a very simple idea. Tell your subordinates *exactly* what you want, and give them as much freedom as possible to give you what you want. Tell the firefighters to take a crew of five guys and the smallest truck, because it's a low priority job, or to bring the hazmat crew along because the fire's at a chemical plant.
K
Sunday, March 21, 2004
"Huh? A conductor that isn't a world class instrumentalist in his or her own right? Who? Which orchestra?"
Sorry - I read the question as "do software managers [normally] write code [in every project]?" i.e. Are they always in the IDE up to their elbows helping out the team.
I didn't read it as "*can* good managers write code"
From my point of view, when the conductor is actually doing his job conducting, then he's not down in the pit playing an instrument.
Philo
Philo
Sunday, March 21, 2004
This is an issue I'm working through right now... thankfully, our team is flat hierarchically and most people can do a lot on their own.
But I really like this quote:
"Should managers code? If they can afford the time then why not. I would always put the management role as a higher priority than coding, since there is likely to be a number of programmers relying only one manager."
And Philo, what do you think of Ray Charles?
mb
Sunday, March 21, 2004
PDF, just to be clear, I think that a technical manager writes code *precisely* so that task organization is obvious and unambiguous. When I say that a technical manager should write code, I don't mean that, you know, he says "OK I'll handle frustrum culling and you write the rasterization system." What I mean is that he writes code to specify what he wants and to describe how concerns are to be separated.
For example:
while (!Console.eof())
{
UI::Window* pWnd = new UI::ApplicationWindow("Tetris 5353.2422b");
GFX::World* pWorld = new GFX::World(pWnd);
GFX::Camera* pCamera = new Camera(x, y, vec);
GFX::Mesh* pSurface = new BezierSplineSurface(ctrlpts);
pWorld->Attach(pSurface);
pWnd->Draw(pWorld->Render(pCamera));
Lang::Parser* pParser = GenerateParser("E ::= \"(\" E \")\" | E op E | atom; op ::= ...");
Eval(pParser->Parse(Console));
}
Then I email Bob, Jane and Tom, and tell them which namespaces/classes I want them to implement. Of course, this example is oversimplified (it leaves quite a bit of necessary detail out), but hopefully I've made my point.
K
Sunday, March 21, 2004
>From my point of view, when the conductor is actually doing his
>job conducting, then he's not down in the pit playing an instrument.
Of course not, but the conductor communicates his desire through the common language of musical notation and so on. He writes code.
K
Sunday, March 21, 2004
There's that wacky dutch guy on PBS who conducts while playing violin and usually facing the audience. :-)
One line of approach to the original question is this...
Could a really good programmer be happy merely managing a software project? Ugh. I very much doubt it.
So is a software manager likely to be a really good programmer? This answer must be the same.
So is someone who is does not deeply understand software (i.e. is not a really good programmer) qualified to make decisions about the software creation effort? No.
Yet at some level in a traditional corporation, everyone has some kind of manager, correct? Typically, yes. This would be perhaps some sort of personnel supervisor with no authority over the software beyond (perhaps) high-level budgetary matters. Keep things flat and make everyone report to the departmental head or vp for such matters.
So is there a *software* manager? No, the lead programmer has final say on decisions about the *software*, and coordinates with sales or marketing types like "product managers" to decide things like product direction priorities.
So "can/do good software managers write code?" The best "software manager" is no software manager, so in a way the answer is no. Failing that, the answer is perhaps yes. But having a manager who *thinks* they can write code can sometimes be worse than having the prototypical pointy-haired boss, so maybe no. Yes, no, yes, no? Again, the best answer is to not need the question.
veal
Monday, March 22, 2004
Incidentally, for the record my stance on the question "must a project manager be able to code?" is "no"
Good management and leadership skills are far, far more important than the basic abilities that are being led. Now there is baseline knowledge that's necessary, and also the humility to recognize one's own shortcomings, but it's entirely possible to successfully lead without the skills of the people you are leading.
Again, it's nice if you *can* lead and do, but the ability to lead is more important than the ability to do.
(and before I leave this to the flamewar, also recognize there's a good chance most people have not worked for a good leader - they're pretty rare)
Philo
Philo
Monday, March 22, 2004
"Incidentally, for the record my stance on the question "must a project manager be able to code?" is "no""
yeah, I have to agree with that.
FullNameRequired
Monday, March 22, 2004
In defense of Philo, contracting, playing a musical instrument, and firefighting DO require a high level of skill. Certainly you can get anyone to lay bricks or jump into a burning building, but next time you're building a house, or yours is on fire, remind me of this thread when you insist on getting a professional.
www.MarkTAW.com
Monday, March 22, 2004
I think the best managers have had substanial hands-on experience of software development before becoming managers.
I never seen a manager that as part of his/her job didn't have to evaluate the work of others, make some design or programming decisions, judge how long work should take and work on a way that different parts of a project should fit together and how different people can work on different parts of a system and still be able to work in the absence of the modules their work needs initially.
A manager that doesn't understand coding, regardless of whether he/she is currently doing it, is a manager can't do the job properly.
There must be a vast number of programmers with 10 - 15 years of experience. They would be far better at management that the clueless wannbe programmer clowns that have conned their way into management without any knowledge of the software development process.
Savage
Monday, March 22, 2004
I think they *can* write code, but they usually *don't* :)
I recently left a job where the software manager spent more time writing code than actually managing or leading his troops.
A software manager has many different duties, most of which cannot be performed by other programmers on the team. Anyone else on the team can code what the manager is doing (hopefully)
Another pet peeve with this particular manager was his ability to write some of the core functionality of a product (for example the business logic), "forget" about exceptions, transactions and all the things that produce stability to the codebase and hand it off to a junior programmer to "polish". Obviously, when the junior programmer struggles and has to rewrite some of the code, there is surprise and shock at "how long it's taking". It never happened to me, but I detested it. Yet another reason why management should understand technical issues, but steer clear of telling people how to do their job.
rant over.. anyone in the market for a (slightly used) soapbox ? :)
deja vu
Monday, March 22, 2004
Is a good manager up to their elbows in the IDE helping out ? The boss should be draining the swamp, not hunting alligators even if it is more fun.
No. Not usually. Because a good manager will make sure that the correct tasks have been assigned to the appropriate people in order to hit the deadline. They should not be assigning themselves to their own project.
In a crisis, then yes they should help but only if they are current and won't get in the way. In general, though, they should be working out why they got into a crisis and what to do about that error.
On the other hand, managers should help out from time-to-time to keep current. Senior air-force officers are expected to fly a certain number of hours to keep their certification but they aren't expected to be top gun.
Woodentongue
Monday, March 22, 2004
> Senior air-force officers are expected to fly a certain number of hours to keep their certification but they aren't expected to be top gun.
Most Wing Commanders and Squadron Leaders are the best flyers of their classes and take pride in topping the scoring ladders for their units.
f something
Monday, March 22, 2004
I'm sorry if anybody thinks it's "flaming," but I think that your analogies are invalid. Programming is not a rote task, and if your project requires that then you're doing something wrong. So comparing the act of programming to laying bricks or putting up sheetrock is misguided.
'Code' is a common language. The code that a manager writes doesn't necessarily go into the product; it's meant to be an unambiguous declaration of requirements.
If you want models of software project managers, look at Robert Oppenheimer and Edward Teller. For that matter, look at successful software companies and products. Good technical managers are able to clearly state what they want and to subdivide the problem to delegate smaller problems to their subordinates (or at least to understand and document the subdivision that the subordinates discover from their own analysis of the problem).
Maybe I'm just not explaining myself very well, because I didn't think that this was a very controversial proposition. There are several different ways to write code, and I certainly don't mean that you should muck around with the nuances of garbage collection semantics when the problem under consideration has *nothing to do* with garbage collection. If I draw a diagram of a wall and specify the materials that must constitute it, I've just written a little declarative program.
K
Monday, March 22, 2004
In that sense then, language is code which causes results in those that process that string of language. This is of course Behaviourism.
It doesn't take much imagination to knock down Behaviourist psychology theories, but then behavioural psychologists classically deny any such thing as imagination.
Simon Lucy
Monday, March 22, 2004
My manager should give me what I need. In my case I don't need code or even architecture from my manager (because I can provide all myself, whether alone or with my team): instead I need him to supply customers, product requirements, time, and money; and he can do that well without writing code.
Christopher Wells
Monday, March 22, 2004
Interesting post Simon. I am actually aware of the fall of behaviorist psychological theories and the work of B. F. Skinner. However, I wasn't formulating a psychological theory, I was describing a philosophy of software project management. :)
But even if I was talking about psychology, your conclusion that I've taken a behaviorist position is misguided I think. Rather than discounting the reality of imagination, I *depend* on that for my whole argument. If I say, "give me an integer N greater than 30 such that a^N + b^N = c^N for any integers a, b, c > 0" and believe that my subordinate doesn't have to be incredibly imaginative, I'm a fool.
Really it's a tangential point, but if you want to know my opinion of effective psychological models, we get back to (surprise) computers and software. But you'd be better off reading Pinker and Minsky.
K
Monday, March 22, 2004
Christopher, that's understandable but I'd argue that the manager you describe is not a software project manager.
K
Monday, March 22, 2004
I usually do something akin to pair programming with the folks that I manage. It's completely voluntary, but I get a lot of requests. Seems to be a good way to stay in touch with what's really going on; it seems good for team health; it's probably a better way to communicate my issues; and I genuinely enjoy it. It's never come up as a negative in any of our "project retrospectives" but it has come up in the positive tally a few times. I might not be high enough up the ladder to be the kind of manager this thread is referring to, though.
slump
Monday, March 22, 2004
K, it's just a matter of terminology: you could also argue that a software project manager is a person who manages *multiple* software projects (simultaneously), and doesn't write code for any of them; whereas the person who manages a single project (and may write code for it) is a project team leader; similarly, a "software engineering manager" may be whoever (e.g. a V.P.) manages the software engineering department (interfaces between the department, the corporation, and its clients).
Christopher Wells
Monday, March 22, 2004
Hmm, I guess I'll weigh in here even though I suspect most opinions are already set in stone...
I am currently a software "manager". I considered myself a pretty good coder, not uber good, but good, solid, sensible.
But I got bored with it. I've experienced at least 3 technical "waves" (RDBMS, OOP, Web) and it all just started to look the same to me.
On the other hand, I really like the challenge of trying to guide a project to completion. A lot of developers have the attitude that projects are always late, good planning is a myth, etc, etc. That's a challenge I can't refuse. Whatever floats your boat, eh?
I interpret my role as 1 part "blocker" and 1 part "shepherd" (wish I had a better term for that part). On the one hand, I protect the team from as much of the noise and paperwork as possible so they can concentrate on doing what they do best. In the second role, I make sure the team has a clear understanding of our short and long term goals and that we always know where we're going and how we're gonna get there.
I used to be pretty controlling when I started. Now I've found that the less you direct the better the results. If we have to build a widget, I simply try to make sure everyone understands what the widget has to to do and why. Unless there was very good reason, I would not try to tell the actual developers how, and that includes code samples.
Now, there may be times when it is necessary to provide code samples to developers, or even for the manager to code. There's always a case somewhere for something. In my opinion, however, part of being a good manager is knowing when to get the hell out of the way of your team.
Just my opinion.
anon
Monday, March 22, 2004
"Most Wing Commanders and Squadron Leaders are the best flyers of their classes and take pride in topping the scoring ladders for their units"
Strange. I would have said that split second reactions is a determinant of good strategic sense ??
Woodentongue
Monday, March 22, 2004
Christopher Wells describes the role of a useful manager well. Such a manager need not be a programmer, since the role he describes does not deal with software issues. That's good and true. K and Christopher Wells, I think, exposed this important distinction rather clearly.
Anon also illustrates this important point, when in writing about not trying to dictate "how" and knowing when to get the hell out of the way.
Although when times get tough, such a good and useful manager may be strongly tempted to overstep that boundary. If they don't have a programming background, or even in most cases when they do, they'll be operating while ignorant, not having a rich enough understanding for that arena. So it's important for them to be almost dogmatic in respect for that boundary.
But I think the reason why a question like that of the original poster can arise is that most shops have one or more superfluous layers of management. ("Blobs" might be a better word than "layers".) In fairness, the creations of these are usually rash responses to inadequacies of the team. A good team needs no guidance in how to get to the goal, how to keep focus. They need only be told periodically which goal to reach, as that goal naturally evolves.
Another aspect that strikes me here is that much of the blame for the existence of these superfluous roles lies not with the upper management who created them, but with the programmers who created situations that made the executive level managers think that might be a useful allocation of funds.
veal
Monday, March 22, 2004
anon,
I *completely* agree with you that a good manager tells his people *what* has to be done rather than *how* to do it. I certainly don't think that he ought to be poking around in some guy's code, telling him to rename his constant "jimmy" to "frank." I agree that he ought to clean up the requirements that come down from above, translate them into the internal language of the team, and divide it into a series of requirements that subordinate teams can satisfy.
What I'm talking about is formalizing that notion. The manager writes declarative code that defines what is to be done, and the team writes code that satisfies those constraints. Whether or not you admit it, this is what's done on an informal basis anyway.
K
Monday, March 22, 2004
[Another aspect that strikes me here is that much of the blame for the existence of these superfluous roles lies not with the upper management who created them, but with the programmers who created situations that made the executive level managers think that might be a useful allocation of funds.]
I love this paragraph.
From listening to developers and managers in other companies, it appears that there are many projects in trouble out there. No surprise I guess.
What is surprising is:
1) Developers, in general, don't seem to care.
2) People are surprised when management tries, often badly, to fix the problem.
Like it or not, management does want to know how long a project will take, how much money it will cost, etc, etc. We, as developers, cannot ignore this, much as we would prefer to. If management ever gets the feeling that a project is out of control, they WILL try to fix it. You usually don't want this. Why? Because they are too far removed from the problem to produce an effective solution.
The only people that can fix problems like that are the team that's doing the development in the first place. Developers cannot avoid this, at least not if they don't want to be messed with.
At the risk of going totally off topic here, I also believe this is one of the factors behind off-shoring. Senior management rationalizes like this: "Hey, software projects are always late and over-budget, so if I'm gonna have to put up with this pain I might as well do it with developers who cost 1/3 of what I'm paying our current bunch".
So, if you want to be messed with by upper management, continue to believe that code is the only important part of your project.
anon
Monday, March 22, 2004
"A good manager should tell his team what to do, not how to do it."
I agree and add "and help them to learn from earlier mistakes and do it better each time."
Woodentongue
Monday, March 22, 2004
Come on anon, who ever said that it's the only important part of the project?
Requirements ambiguity is partially responsible for the huge number of project failures out there, and that's going to cost you dearly whether implementation is in NYC or Mars. What's the clearest method of stating requirements? It's writing acceptance or usage code (even/especially when that means using your own domain specific language).
K
Monday, March 22, 2004
[Come on anon, who ever said that it's the only important part of the project?]
Of course, I was generalizing. I should know better.
Frankly, I don't disagree with anything you've said in this thread. Sorry if it sounded like I did.
anon
Monday, March 22, 2004
OK, I apologize, I thought that you were responding to one of my posts with that comment.
K
Monday, March 22, 2004
[What's the clearest method of stating requirements? It's writing acceptance or usage code (even/especially when that means using your own domain specific language).]
Thinking like a programmer.
So who is going to approve your "requirements"? How well will they understand your code?
How many real world problems can be expressed effectively in code? Who is going to translate these problems to code? Who is going to debug this code? Who remembers Z? Who can tell why it and it peers never took off?
Who has been watching too much of the Matrix?
Erik
Monday, March 22, 2004
I think the problem arises when the manager spends more time coding than managing. I'd like to see a manager manage how the rest of us organize our code. I'd like to see more architectural thinking about what we do ... too many managers will just jump in to get a job done rather than think of how the job could have been better designed from the get go.
Me
Monday, March 22, 2004
Erik, I'll assume that you're trying to be funny rather than snide with your 'Matrix' comment.
Anyway, it seems like I'm already identifying myself as a radical here but I think that it's programmers all the way up. First of all, people are *already* little computers. I don't think there's really any question whether or not managers give their teams programs which the teams must satisfy. The question is *how clear and simple* that program is. If you don't recognize the connection, it's quite possibly going to be ambiguous and complicated.
>How many real world problems can be expressed
>effectively in code?
All of them. Think about it.
K
Monday, March 22, 2004
K,
You're right, you are radical :-) And about the Matrix, I like it as a piece of entertainment. The comment was merely meant to explain that I think that when you think everything can be expressed in code -- which is what drives the Matrix -- you must be getting carried away a bit.
There are plenty of smart people -- some of them here -- who can explain much more eloquently than I can why it is not programmers all the way. Programmers have there pros and cons, just like anyone else.
People need certain qualities to perform certain tasks well. Unfortunately, some of these qualities don't mix well, which is why some people can do some things very well and be terrible at other things. More often than not, this is a question of apptidude, not intelligence or training.
So unless one programmer is building something for another programmer, at some point she is going to interact with people or concepts beyond here field of expertise.
But you are right about directions needing to be clear, preferably unambiguous and complete. Or at least as much as reasonable. The world we live in is neither. Talk to Hawkins is you think otherwise.
Erik
Tuesday, March 23, 2004
Their pros and cons, obviously...
Erik
Tuesday, March 23, 2004
[First of all, people are *already* little computers. I don't think there's really any question whether or not managers give their teams programs which the teams must satisfy. The question is *how clear and simple* that program is.]
Just to show you why you might be radical and biased.
Although people are organical computers in some sense, they are not little computers. Their capacity, while not close to really measured, is far beyond any articifial computer of this age and many to come, even if Moore's law (or is it More) continues to hold.
Next, if the program is to be clear and simple, it needs to be in a language that is understood by this people computer if you want to rule out translation mistakes.
The internal representation of this human computer is still somewhat of a mistery, although some people make good educated guesses (you may want to read Steven Pinker).
The exetrnal representation is natural language though, something you seem to ignore. Because that is certainly not code, not clear, not unambiguous, not anything really, but subjective and highly dependent on context.
So if that clear and simple program you speak of needs to be anything, it needs to be in natural language, complete with sounds and pictures, as our human sense and mind can best interpret. And even then we're still interpreting.
Unless of course you can find a way to uncover the internal representation, find that it is universal, and find a way to connect to it directly, not unlike what you see in the Matrix or similar fiction.
Too much for one afternoon, me thinks.
And about your bias, I think you love your hammer (code) too much and are seeing nails everywhere.
Erik
Tuesday, March 23, 2004
Erik, I *have* read Pinker's pop-sci books, and you might want to give them a second read because he thinks that people are little computers as well. :)
Sure we're faster at certain tasks than a desktop computer might be, but I wasn't suggesting that we're desktop computers.
Yes English is ambiguous, but there are many subsets of English that make suitable 'programming languages'. NASA is a great example. Richard Feynman's famous criticism of the tremendous organizational complexity at NASA was representative of the ad-hoc mutually incompatible languages that NASA managers came up with. Just read through the worst of the documents he cites, and I think that you'll find that the mess is familiar to any high school kid who's tried and failed to construct a large and complicated program.
Maybe you're right, maybe I'm overextending a familiar concept. However, I think that the metaphor is appropriate and that a lot of other people here agree. A great example of this phenomenon, I think, is the fact that all companies try to mechanize their core production process. They do it to control the quality of their output, but that requires a formally specified program.
And since I'm already such a radical, there's not much harm in mentioning that I think that this metaphor is only going to be extended further in the future, and that within my lifetime, little kids will (explicitly) learn computational concepts in Elementary School. And the market for "generic programmer" will be the same size as the market for "general arithmetician." It's already happening.
Gerry Sussman has a lot of useful stuff to say on this topic.
K
Tuesday, March 23, 2004
I am not disagreeing that humans can be compared to computers in many aspects. It is just that there are also very many differences too that you kind of glossed over.
So jumping from a computational theory of the mind to the conclusion that everything can be put in code is a bit too much.
Especially if you have no concept of what that code might look like. And because of what we do know about this computation shows that there is no similarity with contemporary computing other than a very abstract one.
Which should tell you that a programmer in the sense of computer programmer bears no resemblence to a "programmer" in the sense of a human computer.
Therefore, it is a bit of a stretch to assume that the code that this computer programmer produces can be any kind of measure for the kind of code that you might need to describe the operation of a human.
So basically, I don't think you should concentrate on the similarities in this case, but rather concentrate on their differences and find a good representation that can be used in both the problem domain and the solution space. And still find yourself good interpreters.
Erik
Tuesday, March 23, 2004
Oh, and as for production processes, I am sure you would agree that you can't simply compare a production process to human interaction.
For one thing, a production process has a well defined purpose and is operating under well known and controlled circumstances.
Of course the same might hold true for many human activities for which computer programs are being constructed, but for many more it doesn't.
Software design, or rather, the design of tools to aid our mind is more like research than production and will remain to be so.
But maybe we are talking of different parts of the product creation process...
Erik
Tuesday, March 23, 2004
Right, it seems like you agree that the metaphor is obvious when it comes to a production process.
But this discussion started out with managing technical projects, which is not necessarily the same as managing a bunch of people who do the same thing over and over again. So what I've been trying to explain is that management works toward a common formal language of the domain under consideration, and expresses business strategy (and so on) as statements in that language. That's what technical teams do too, and good technical managers synthesize and distill the knowledge of their teams in this way.
K
Tuesday, March 23, 2004
>Software design, or rather, the design of tools to aid
>our mind is more like research than production and will
>remain to be so.
>But maybe we are talking of different parts of the product
>creation process...
Yes we're talking about different parts. I didn't mean to suggest that software development is necessarily assembly-line work. I also didn't mean to suggest that technical managers 'program' their subordinates.
K
Tuesday, March 23, 2004
Ah, so when you said code, you were not being radical so much as liberal :-)
You would consider a well written functional specification in natural language, augmented with graphics, story boards, formulas, or whatever is relevant to explain the problem and limit the scope as code then?
In which case you might take a shining to Suzanne Robertsons Voliere framework for specifications...
It allows you to specify both your goals and your acceptance criteria in a comprehensive and structural fashion.
Erik
Tuesday, March 23, 2004
This Volere thing is interesting, I'd never heard of it before. Thanks a lot for pointing it out; I've been reading over the website. Here's an article that said a number of things that I agree with (though I don't know if their formal structure is necessarily the best one, I'm sure it's a good fit for some projects): http://www.volere.co.uk/fundamentals.pdf
>You would consider a well written functional specification
>in natural language, augmented with graphics, story
>boards, formulas, or whatever is relevant to explain the
>problem and limit the scope as code then?
Not necessarily. If the graphics and so on form an unambiguous analytical model which people can reason about, then yes I would consider both the model and the derived constraints to be code. In that case, actual software could be written to simplify the act of reasoning about the model, and that's where I think the critical management activity happens. You know, something like Sim City for city planners (though of course Sim City is probably oversimplified for the job of city planners).
K
Tuesday, March 23, 2004
 Recent Topics
Fog Creek Home
|
