 |
java.net Forums
Since the first publication of The Mythical Man-Month in 1975, no software engineer's bookshelf has been complete without it. Many software engineers and computer scientists have claimed to be "on their second or third copy" of the book. Now, Addison-Wesley is proud to present the 20th anniversary edition-and first revised edition ever-of Fred Brooks's now legendary collection of essays on the management of computer programming projects. The 20th Anniversary edition is an updated, enhanced re-release of the Brooks classic. Included are all of the existing essays that were originally presented, with the addition of three new essays assessing the current status of software project management. Brooks's well-known 1986 article, No Silver Bullet, is also included. This 20th Anniversary edition is a major event in computer publishing.
Discussion Moderator:
John D. Mitchell
Showing messages 1 through 146 of 146.
-
The Humane "Bullet"
2004-05-24 17:30:27 johnm
Is the real lesson that was learned, lo, those many years ago (and rediscovered over and over again), the simple fact that even in the most abstract of endeavors, people matter?
That we may put aside the childish dreams of the silver bullet and discover what lies beyond.
--John
-
The seeds of lots of "new" ideas are there
2004-05-19 18:39:20 cbare
My yellowed and faded copy of "The Mythical Man-Month" is a 1982 reprint which I got at a used book store for 3 bucks. Reading it after being exposed to more recent software engineering books, I was surprised at how much of what passes for modern software engineering is in this book.
A lot of the "agile" doctrine is here: The emphasis on small highly skilled teams, emphasis on testing, coding for ease of maintainence, planning for change, etc.
In particular, on page 15 he states:
"For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation."
Then in chapter 4 he goes on to say that "architecture, implementation, and realization [...] can be begun in parallel and proceed simultaneously."
How agile can you get?
The part about formal definitions in chapter 6 is slightly suggestive of model driven approaches that are so hip and trendy these days.
It's amazing that the seeds of so much are in such a small book. Don't be put off by the fact that half the book is ridiculously obsolete -- the other half is packed with insight into the process of creating software.
-
No Silver Bullet?
2004-05-19 14:02:37 johnm
Is there a single silver bullet that will make development at least one order of magnitude better?
Is there some combination of regular bullets that, used together, will make software development at least 10x better?
-
Chapter 15: Self-Documenting Programs?
2004-05-18 10:18:11 johnm
Are approaches such as the current buzz magnet, Model Driven Architecture the holy grail of self-documenting "programs"?
Or are they just another in a long line of hoped for salvation that is destined to be dashed?
-
Self-Programming Documents
2004-05-18 19:21:29 tackline
I think the problem is that languages such as Java are just far too low-level for the bog standard business application. Developers of such applications should not have to worry about squeezing through remote EJB session, persistence or the intricacies of moving data around web servers/smart clients. It's not new, 4GL of the 70's where doing it in a proprietary, bounded way. For technically interesting programs, or section of programs, MDA doesn't appear to bring anything to the table.
UML works best as object code. I don't want to spend time fiddling about with drawings, but graphical summaries and navigation can be handy. When I draw diagrams I don't even bother with the boxes. If I don't have a scanner or whiteboard camera handy, then notepad makes a better diagram editor than Together/J or Visio.
-
Chapter 14: Schedules
2004-05-18 10:09:00 johnm
How are schedules handled in your organization? In particular, how are changes to the schedule handled in the face of changing requirements and/or development time/effort estimates?
How does the technical group interact with the rest of the company in terms of scheduling?
Are schedules mostly just a fantasy game that the non-techies play amongst themselve and periodically use to beat up the techies?
-
Chapter 13: Releases
2004-05-18 10:03:11 johnm
How does your team manage releases? Does it use the big-bang approach or a stream of frequent releases or something in-between?
Do you release based upon marketing and sales dates or feature lists or what? What criteria, if any, are used to decide whether some piece of functionality actually makes it into the release or not?
-
Chapter 13: Integration testing
2004-05-18 09:51:52 johnm
How does your team deal with integration issues? For instance, how often do you integrate and how often are the integrated components tested?
Do you use any (special) tools and/or frameworks for doing integration testing?
-
Chapter 12: Quality tools?
2004-05-17 20:09:05 johnm
I'm a bit confused... If code is the critical product of programmers' efforts, how come code is so often treated so cavalierly? For example, how many programmers and organizations do you know that don't use any source code management system (SCM)? Even worse, IMHO, is the use of SCM's which have a clear history of corrupting if now outright destroying data.
Do you think the problem is ignorance or incompetence or what?
-
Quality environments
2004-05-18 19:28:38 tackline
How many organisations lack version, workflow and security management for documents in general? Isn't it a problem of poor user interface and non-existent integration into the shell (desktop)?
As for visibly source destroying "safes": Avoid the temptation to upgrade. Stick with a build that makes only the occassional minor corruption. Back up regularly, together with raw source files.
-
Quality environments
2004-05-18 22:09:03 johnm
Well, your point about the larger, organizational context as being a major factor is true but even directly amongst techies there's a lot of people who don't use SCM and even more that use poor SCM "solutions" (often poorly). What's the techies excuses?
As for your second comment, I'm really confused. I was asking about why people are willing (to continue) to use SCM products that have literally destroyed the very data that they are supposed to be protecting. So, I'm not sure how avoiding upgrades relates to that. Thanks.
-
Chapter 11: Regression testing
2004-05-16 10:51:50 johnm
Does your organization mandate the creation and use of automated regression tests?
Do you actually create and use automated regression tests?
How often are the regression tests run?
Do you find regression testing worth the effort?
-
Chapter 11: Regression testing
2004-05-18 19:23:11 tackline
A company I worked for talked big about testing. However, after my team leader found a bug in my code he told me not to add a test for it (but sometimes I'm disobedient).
I'm curious as to what mistakes are made and caught by the programmer before their code is checked in. Obviously syntax errors, but what about other bugs caught by the compiler, bugs actually caught by unit tests (at least one per monkey tested class in my experience), by monkey testing or just things that cause the programmer to break and look up something/scratch head (like returning a List of unspecified element type). I hate doing this sort of thing myself, preferring to obliterate any trace or memory of my mistakes as soon as possible. Perhaps it needs some automatic logging.
-
Defect information?
2004-05-17 19:47:14 johnm
Heck, does anyone's organization who's reading this use any defect information in the decision making process (for things like deciding releases)?
Has that practice changed in recent years due to e.g., security vulnerabilities?
-
Chapter 11: Throwing one away
2004-05-16 10:47:13 johnm
Have you written a first version with the intention of throwing it away and then actually threw it away?
How do you deal with cases where the prototype was not thrown away? Do you do anything different in the development of a prototype when you're pretty sure that it won't actually be thrown away?
How does doing a prototype conflict (or not) with the Second System Effect?
-
Chapter 11: Throwing one away
2004-05-18 19:31:15 tackline
There was an instance when I (partially) threw one away anyway. My second commercial system and first in Java. A major problem was that it was OTT. I started with a new empty program, copying and pasting bits of the old one in as appropriate. Also gave me the opportunity to switch over to the new (as was) AWT event model. Still an OTT second system, but less so. In general I prefer a gradual refactoring approach, providing it's not a port between incompatible systems.
DSDM, allegedly, takes 'prototype' literally as just an earlier version, which is kind of useful to know when interpreting some DSDM literature.
-
Chapter 11: Throwing one away
2004-05-18 10:46:11 jerry
What about doing your prototype with a technology that just won't be used in your organization for a production version?
You could select a language that will not be supported by operations - Python, Smalltalk, Lisp or anything exotic enough that operations won't touch it (note that I'm *not* implying that either of these languages would not be fit for production use).
Anorther approach is currently used by the guys down the hallway who base a prototype on a library that is not being supported any more. That takes care of the problem also.
-
Chapter 11: Throwing one away
2004-05-18 10:53:04 johnm
In those cases, doesn't that usually mean that the prototype will stay in existence forever?
...and be much less likely to be maintained or updated?
-
Chapter 9: Representation
2004-05-13 17:31:27 johnm
Representation is the essence of programming.
Have the wild profusion of different ways of representing programming helped us progress in the last 30 years? I.e., we now have all sorts of fancy tools and frameworks and languages that cost us a lot to use (be they cash or in time and effort) but have they really helped us do a better job? Have they helped us more than the brute force improvement that we've gotten out of bigger and faster hardware?
-
Chapter 9: Costs
2004-05-13 17:04:24 johnm
What sizing and space costs matter today?
Is there more focus these days on things like bandwidth usage and screen real estate than programmatic space? Is that a good thing?
How do needs such as hot-deployment and reliability and robustness impact the costs of system development?
Technologically speaking, is the crucial cost developer time and energy?
-
Chapter 8: Productivity and Language Choice?
2004-05-10 14:31:56 johnm
In your experiences, do you find a large difference in your productivity based upon the programming language that you use?
If so, how much of that is attributable to the language itself versus the differences in available support libraries and frameworks versus various tools?
Have you or any organization that you've worked for done any experiments or e.g., before/after measurements comparing productivity due to these factors?
Have you found some languages good for e.g., "write only" projects while other's are good over the long haul?
What do you think of "little languages" / "domain specific languages"? Do you create them in your projects? What is good / bad about them?
-
Chapter 8: Productivity
2004-05-10 14:23:09 johnm
Does anyone work in organizations where they formally track developer "productivity"? If so, what methods of measurement are used?
In less formal organizations, what measurements or heuristics are used?
Are the results used in an ongoing manner or are they only used before (i.e., for estimation) or after (i.e., for learning and/or blame)?
-
Chapter 6: Assessments
2004-05-05 13:09:08 johnm
Do your organizations use independent auditors at all or only when forced by the customer or as a matter of course?
If they are used, who do they actually work for?
Do they actually help get things done or is their job just to pee on things? Are their findings shared with all of the parties involved?
Are they around on a regular, periodic basis or just for milestones or just at delivery or what?
On the other side of the coin, when your organization is the customer, does your team audit outside systems or are you stuck with things that have been mandated by higher-ups or does your company just trust the other side or what?
-
Chapter 6: Assessments
2004-05-05 18:25:26 rickcarson
My current 'character building experience' involves dealing with some massive classes (over 10k loc), which were produced some years previously (prior to my involvement) by a big outsourcing firm from India.
The code doesn't follow java naming conventions (*everything* starts with a capital letter -
is it a class?
is it a variable?
No! Its a whothefrakcantell!!!
)
Hashmaps... oh the horror... hashmaps which contain hashmaps which are modified as unspecified side effects of calling methods... *twitch*
Comments are in bizzare and unexpected places... I could go on.... Suffice it to say that I suddenly realized one day that it had been written by VB programmers and a lot of things fell into place.
Anyway, the code had been audited by an outside organization, and when I read their report, I didn't know whether to laugh or cry.
The auditors had decided that they would not actually look at the code, instead they would run some code metrics tools, and make some generalizations. The code metrics tools complained about a bunch of things, some of which were irrelevant (yes... EJBs do strange things and don't follow good OO rules... get over it), some of which were relevant (the file is too big - response from outsourcing company "get stuffed").
Some however were just incredibly unhelpful. In particular, they complained that there was no 'standard' header comments on files, and that there was too much commented out code.
So the outsourcing company went through and removed all the commented out code - including:
(1) code that shows they tried to do something, and it didn't work
(2) code that shows how you would do something if you wanted to make a particular change in the future
Why is this important? Because it removes all their 'intentions', all the archaelogical evidence of what they *think* the code is supposed to do.
Imagine if at the start of every CSI:Miami episode they rocked on up, and said 'gee, this crime scene is filthy! Lets scrub it till its spick and span!' - their job would be, a tiny bit harder, no??
Code has a couple of jobs:
(1) communicate with the compiler (comments do not effect this)
(2) communicate with anyone using the code as an API (solution: slap in the javadoc, does NOT require removing normal comments
(3) communicate with the poor soab that has to maintain it. The absolute #1 biggest thing here is to communicate *intentions*, what does the writer of the code think it is doing, and what did they intend for it to do??
If I come to a convoluted section of code with a horrible (yet incredibly rare) side effect - how do I know whether or not that was what they intended???
In this case, the outside auditors should be LARTed something chronic. Commented out code is *never* *ever* a bad thing.
-
Metrics do NOT a brain make!
2004-05-06 10:11:53 johnm
Anyway, the code had been audited by an outside organization, and when I read their report, I didn't know whether to laugh or cry.
The auditors had decided that they would not actually look at the code, instead they would run some code metrics tools, and make some generalizations.
Sounds like those "auditors" are incompetent shouldn't be trusted. Hello?! McFly?! The proof is in the pudding and metrics have no sense of taste.
I had a case where I was helping a client deal with a problematic custom software deliverable from a less than stellar contractor. The system was horrible at all levels (can you say "catastrophic" :-) and our report showed how and why that was so. Heck, we could even show willful intent! Anyways, the contractor company tried to attack our findings by using one of those metric based, automated assessment services. Talk about stupid, the "evidence" they presented just reinforced our points about just how bad their system is! Thanks for playing. :-)
-
Metrics do NOT a brain make!
2004-05-08 22:05:57 rickcarson
Actually, I see a lot of people round hear say the same thing, that you should remove unneccessary comments. Also the XP guys seem to have a big thing on aplying YAGNI to comments.
It seems that most of these people have never had to maintain their own code, let alone someone elses.
Get them to do some maintenance, then they'll become readability/explicitness freaks too! ;-)
-
Utility of comments
2004-05-09 12:44:59 johnm
One of the arguments made for keeping comments to a minimum is that, over time, the comments often get out of sync with the actual code.
Of course, there are plenty of people who are using such guidelines as an excuse for not commenting even though there code is horribly unreadable. :-(
-
Utility of comments
2004-05-14 02:44:17 jwenting
Do you really think their comments would be of higher readability than their code?
-
Utility of comments
2004-05-14 09:22:04 johnm
Depends on who you mean by "they". :-)
Seriously, I've seen code written in very dense styles have very well written comments and I've seen very verbose coding styles used with horrendously bad comments. Of course, most code is somewhere in between on both axes.
Have you ever used approaches such as Knuth's Literate Programming?
-
Chapter 6: Communication
2004-05-05 13:05:55 johnm
How do specification documents work for you? I.e., do you find them to actually (a) articulate what needs to be done and/or (b) clarify the intersections and/or (c) provide ways to know where to draw the lines?
How do specification documents work against you? I.e., how does who writes them, when they are written, and why they are actually written make things difficult if not impossible?
How do specifications get revised in your organizations? Heck, do they get revised at all once they have been approved? If so, how does that revision process help or hinder?
How are discrepancies between the specification and implementation (a) detected and (b) resolved? How about in the case when you have specifications, tests, and implementations?
Do you have different types of meetings for different types of communication or decisions? Do the meetings actually help at all or do you find that they are just excuses to make it look like people are involved?
Do you document your system, architecture, designs, code, tests, scripts, processes, etc.? Do you document why decisions were made or just the how things work?
Is there a process by which proposals are made, reviewed, decided, and acted upon in your organization? Does a lot of stuff get dealt with outside of whatever formal processes that are in place?
How do your teams bring new team members up to speed? Do you limit the rate at which new members are accepted? How do you develop trust in the new members?
Do you have to deal with interoperability between your system and others? How do you deal with that? Does portability really matter to your organization? Is there testing to ensure portability/interop. or is it more of a seat of the pants thing?
Do you use and maintain change logs? Is this done on an ad hoc basis or are there conventions that you use the task/issue tracker and/or source code respository logging?
-
Chapter 6: Communication
2004-05-05 18:30:47 rickcarson
Specs are absolutely fantastic for one thing, and one thing only.
They help you figure out whether the analysts have a clue.
If not, ignore them and do a run around the analysts and figure out how to get some face time with the clients to find out what they *really* want.
-
Chapter 5: Incrementalism vs. Featuritis
2004-05-03 10:10:10 johnm
Brooks quotes Ovids:
Add little to little and there will be a big pile.
So, where does the line get drawn between incrementalism and featuritis?
More importantly how can we deal with the various biases and pressures that insidiously lead to featuritis? For example, with respect to design, refactoring is a powerful tool but how do we preserve the integrity of the architecture while accomodating change?
-
Chapter 5: Incrementalism vs. Featuritis
2004-05-03 23:45:36 rickcarson
Oh, thats easy.
You need to keep one eye on the design as you add features, and figure out when to update the design, and when to just 'slap another one in'.
Its the difference between trying to cram that tenth student activist into an already full mini, and knowing when you need to upgrade to a van or bus.
Some guys (Martin Fowler?) refer to this as Continuous design.
Whereas I've read a lot of XP literature that suggests not doing any design at all....
I think its kind of a Zen Master thing. The Master of Design Fu can sit there on the mountain freezing his butt off for a couple of days, meditating on the Dao of the Code... then he comes down off the mountain, changes three lines of code, and viola! Its done.
Whereas those who have not Mastered Design Fu spend weeks if not months writing tens of thousands of lines of code, and then refactoring them, and refactoring again. To solve the same problem, but in a worse and less flexible way.
Here's the problem: the Zen Master just looks like a lazy SOB, whereas the XP Ninjas (in the old days we called them Cowboys) are running around loudly going "Hyah!" at anything that moves, and so it looks like they're doing a lot more work...
-
Emergent Architecture?
2004-05-04 07:42:44 johnm
Thanks, I love the metaphors. However, unless I'm missing something, you're talking about design and I'm asking about architecture. In this respect, the quesion is... Is architecture something that is / can be emergent? I.e., given the softness of software, I'll grant that you can mutate the design from a small car to e.g., a van. But what about going from a small car to a boat or an airplane?
-
Emergent Architecture?
2004-05-04 20:16:41 rickcarson
My apologies.
I've reread your original comment though, and you *did* talk design and architecture in the same sentence. :-)
-----
Short Answer: if you're turning a car into an airplane, you need to radically change your design. Step 1 will be to throw away your existing architecture, along with assumptions and so forth...
Actually, now that I think of it, Step 0 is to go back to the orginator of the requirement and find out whether the car *also* has to be a plane, and whether it ever has to be a car *and* a plane *at the same time*.
:-)
-----
You also might find it useful to think about infrastructure. And how design, infrastructure, and architecture all interrelate.
Of course, as soon as I mention infrastructure, you probably think the hardware / network side of things. But I also mean the *internal* infrastructure. A set of classes I looked at recently was quite thought provoking:
Each of the classes individually looked like a lot of effort had been made to make them very generic. To that point, they made very few assumptions....
But then all the useful decisions have to be delegated to other very generic classes... and so on.
Till it becomes a very 'all or nothing' affair. In other words, they'd come very close to building what I would call an architecture neutral framework.
Even though it is 'architecture neutral', there is still an enormous amount of interdependence (the 'infrastructure'), so that you could reuse all of it (at once) or none of it...
(To put it simply: it was a bad design)
Whereas architecture to me indicates also elements of the external infrastructure, the 'environment' in which it operates.
A car and an airplane operate in very different environments. Even when their environments look superficially similar (ie when the plane is on the tarmac or parked) they are actually very different. You are unlikely, we would hope, to get a speeding ticket from a cop when you are taking off, for instance. 2000 feet up, you are unlikely to encounter a 'stop' or 'give way' or 'no right turns' sign (or traffic lights). On the other hand, when returning home in your car you are unlikely to be required to circle the block until the radar tower tells you you can enter your driveway.
A less fanciful example is taking a stand alone application, and turning it into a client/server (n-tier) application. Okay, so the architecture has changed. The first thing to do is to take a look at the design 'big picture'. Which of our original assumptions no longer hold true? (Most of them, probably :-)
Only once you work out the implications at the big picture level should you hunker down and start redesigning individual classes.
You absolutely cannot just 'incrementally refactor' a stand alone app into an n-tier application - and still have a good design. Even if I thought it were possible to slowly evolve from standalone to n-tier (which I don't), when the n-tier 'emerges' you'd need to go and do a major redesign.
In real life, what happens is that you discover that in the next release, your standalone app is expected to have a new feature listed (in the fine print of one of the really long boring spec documents that nobody thought you'd read) of being multi-tier or client server.
And (true story) when this happens in real life, you go to the management, and tell them that they've got to be freaking joking. And then they look sheepish and go 'darn, he caught it'. Then you must rant and rave about how impossible it is (bonus points for foaming at the mouth or self mutilation), and get them to admit that its utterly inconceivable in the required time frame.... and *then* you go up on that mountain for a deep think, because if you can pull it off, you're a miracle worker.
:-)
Given the scenario that someone comes to you and reveals a large change all in one go, there will be architectural constraints which bubble up to the big picture design level. Eg 'we will use the best servers, so long as they are IBM' (I've often seen in-house hardware requirements supposedly vendor neutral, but massively biased towards a particular platform) or 'we have this Sun server already, so thats what we're going to use'. And given that your hardware is often set in stone, so will your middleware... etc.
The process of design then becomes 'how do we do the best we can within this set of architectural constraints'. Which is why I think a lot of people view architecture as 'above' design.
You should be aware though, that in ongoing development, sometimes you do get the requirments changing and moving in a particular direction little by little. Sometimes this can happen because there's a large overall budget, but each release/iteration only has a tiny portion of the budget. When you do get feature creep, you can usually look ahead, figure out the general direction they're heading in, and then factor that in as an unspoken requirment (particularly if you can get confirmation of the ultimate end goal) that it has to support the changes you know you're going to have to make in the future. So you build an internal infrastructure with that flexibility in mind. (Note the difference here with XP - which assumes that you don't know what changes will be required in the future. When you do know, then those parts of XP which rely on that assumption are out, and proactive design is in (part of knowing when to break the rules, when to bend them, and when to go for a sulk up on top of the mountain))
---------- The point -------------
When you are doing pattern based development, a lot of this 'infrastructure' starts emerging, and you end up with a lot of classes simply to support the infrastructure.
On the other hand, your architecture is unlikely to 'emerge' because often its the limitations of the architecture that you're trying to work around. Architecture defines the big landmarks on your map. The mountains, the oceans, the pits of despair, the outer darkness from which there is wailing and gnashing of teeth...
... but... I digress ;-)
-
Chapter 4: Architecture? What architecture?
2004-04-27 17:34:20 johnm
Is it true that the vast majority of systems have no coherent architecture?
Is Brooks' definition of architecture really just another way of talking about end-user usability / interaction design? What about the interface between the different facets and components of the system?
Is the lack of real, system architecture (i.e., "conceptual integrity" across all of the dimensions of the system) the fundamental failing of systems?
Is architecture something that can even possibly be emergent? Or, is it something that has to be laid down by fiat, up front?
Is the XP notion of a "system metaphor" just an alias for "architecture" or is it just a helpful guideline or is it a complete replacement for an "architecture" or, does it have basically nothing to do with architecture at all?
-
Chapter 3: Bargain Developers?
2004-04-22 17:52:15 johnm
Is there any disagreement that there's at least a 10 to 1 difference between the best programmers and the worst?
Does anyone work where that fact is actually taken into account?
How does this fact interact with Brooks' Law? For example, with all of the hoopla lately about offshoring, how is offshoring an advantage over a small, very high-quality team?
-
Chapter 3: Bargain Developers?
2004-05-01 07:21:32 bblfish
I have found this to be very much the case. Two examples should help:
At AltaVista the main engineer who wrote the seach engine - a very quiet English man who only wanted to be known as m3b - wrote it in 3 months from scratch. Not liking the complex threading library written for Digital Unix he later wrote his own. He enjoyed calculating the mathematical optimal number of instructions required to do a function and then finding the optimal way to get there. He wrote the engine using vi, and only worked off a black and white X terminal. Engineering wise he was leagues above everyone else in his knowledge for this type of thing. He suffered at some point severely from Carpal Tunnel Syndrome (I think), and this was a major worry to the whole enterprise. He was a genius optimiser. Which made it very difficult for him to understand the other side of a search engine, namely the need for front end flexibility where what needed to be optimised was not so much cpu cycles, but human cycles. Management (at least those directly in contact with him - which at DEC tended to be ex engineers) understood his value very well. The odd thing in some ways is he did not care about it that much. The aproach of everyone to him in this case was very much that of the assistants to the surgeon. It took a very long time before others could even begin to take over his work. The first thing they did was to start commenting his code.
After I moved to a small startup in San Francisco I worked with a team that was trying to setup some mode of XP Programming. There again there was an engineer who was way more productive than anyone else and had a very good understanding of OO Patterns and concepts. He was at times unbearably pretentious, and his skills were not as high as those of some at the DEC Research labs). But he was the moving force behind a lot of what happened there. His only editor was emacs, and his workstation a Solaris box. Pair programming with him was more an occasion to learn something, and in that sense was very important and helpful to me. He also had a degree in English literature, and so was very fluent and got on very well with management.
Since I have been in Europe though I have had the occasion of working with some very bad companies, with people who had no Version Control Systems, or who wrote code seemingly getting paid by the pound, or where a piece of software seemed to have been architected in such a way as to make sure it would fail. There are horrors worthy of Dante's sojourn through the depths of Inferno. Were there companies like that in the US? Some of the stories I heard while there would seem to suggest so too. I think I was lucky that I did not come across them in California.
I think it does help of course when you have as in Silicon Valley such a huge computing industry, as it is much easier to find managers that have lived the industry they are working for, can make the right distinctions, and don't for example, as I see so often in Europe, have job descriptions mandating the knowledge of a particular editor - thereby rejecting in one go the two key movers I described above.
-
Non-bargain companies?
2004-05-03 09:11:57 johnm
Do you think the inferno that you've experienced working with some European firms has to do with cultural differences, bureaucracy, labor laws, (lack of) competitive forces, and/or other things?
In hindsight, are there any signs of such problems that you can share with us that might help people identify crappy teams/companies before they actually join the teams/companies?
-
Non-bargain companies?
2004-05-03 18:24:48 bblfish
I can speak of the following examples.
The French institute I worked for remotely from California had a very interesting project on the semantic web. The engineer who had written it though had written a huge spaghetti code of classes containing only println statements. The only sensible solution was to refactor the whole code into the Model View Controller pattern. But he wanted me absolutely to fix his spaghetti code. I refactored nevertheless, included an ant build, introduced them to version control, but got a load of abuse as a result.
The best explanation I have here is that he was frightened for his job, which he really had no cause to be given the ridiculously low salary.
Returning from the US I arrived in London penniless. So I had to accept work at a small startup in England, where the problem was that management had just sacked 99% of employees after the dot com bust. They had to employ me and a contractor after realising that they had sacked too many. So we were 4 engineers and 1 manager who drank at least 5 Starbucks Grande's a day and smoked like a steam engine. Not surprisingly he kept having to go to hospital. I think he was in way over his head. They had cut the parts of their software into little chunks with each of them communicating over RMI, in order apparently to facilitate modularity. I think they expected that if they put the pieces together the RMI serialisation would not happen - which would indeed be a nice feature. Needless to say performance suffered abominably. One of the programmers who had been left from the old company spent a huge amount of time writing a 20 page database layer which I had to use before he had finished writing it. The problem was he did not comment his code and all his methods returned Collections of objects, so there was no telling what was going to be inside them. The manager knew about JDO, but why they did not use such a solution I don't know. I think they wanted to optimize. But they were under time pressure.
Here the problem was not bureaucracy or lack of hard work. It seemed to be the British disease of knocking one's head hard against a wall instead of just using the door. The Brits love to feel tough.
In Holland on the other hand it was forbidden to work over-time (though I managed to). I knew that something was fishy in the job I was given, as the story of what I would have to do was incoherent and contradictory. But the pay was so good, it was difficult to say no. Soon after I arrived my line manager who had a T-Shirt which said "I will replace you with a shell script", started having to take injections for diabetes. He was a really good shell programmer, but his comunication skills left very much to be desired. It was incredibly difficult to get any information out of him other than how badly the whole organisation sucked, which might have been true, but got very tedious after the 20th repetition. Needless to say his position was terminated. So instead of doing Java Programming, which is what I enjoy doing, I learned shell programming. Holland is a very beautiful country, and I used the time there to bicycle from one end to the other (I must have cycled over 2000km)
My only explanation for why anyone whould pay me so much to do such silly work was that I was employed as a back to catch anything that may come crashing down when they sacked him, which is probably the best thing that happened to him. Sometimes if one does not like where one is working it is just best to go.
England, France and Holland are very different countries. In each of these cases something very different went wrong. Clearly I was not up to dealing properly with the situation.
I think there is a clear pattern. In each of these cases I was dealing with people immersed in problem above their current abilities. But there was an arrogance preventing them from acknowledging that. Perhaps the arrogance had got them into a situation where they could not but act that way, for fear of losing face or something similar.
But on second thought, none of this was any worse than elsewhere. In California there were crazies and political intrigues a plenty. But then I really enjoyed my work so much that nothing was going to sidetrack me. Perhaps it is just the California sun that does that. But it also helped to know I was part of a company with people whose skill and knowledge were way beyond mine.
So my advice is to always seek the company of betters, and to learn from them.
-
Fear
2004-05-04 09:12:16 johnm
Aha! So fear really is the Root of All Evil(tm).
Fear begets more fear and poor communication.... For example, actual arrogance being a "bluff" to cover one's insecurity (otherwise, why does the person feel the need to act out arrogantly)?
Given your stories, would it be fair to say that the key, underlying fear that all of these people were expressing was that they would lose their jobs and have to suffer all of the real and imagined consequences thereof?
-
Fear
2004-05-04 23:04:58 rickcarson
Isn't there some quote about the tyranny of those without power?
The people in the examples had no power to effect change, and they were fearful.
The author also took one of the jobs out of a powerless position (because he had no money).
The problem with taking a job because you have no money, is that as soon as you have been paid a couple of times, your primary motivation for having that particular job is gone...
Interesting that extremely wealthy individuals are often motivated by something other than money. One of the reasons why when I'm asked for career advice by aspiring IT code monkeys *why* they want to get into IT... if its because of 'the big money' I try to steer them elsewhere, or point out that only those who really love the tech have the money.
Equally pathological are those who get into IT 'because its the hot industry' but gravitate towards the low end jobs because they don't think they're 'smart enough' to do coding. Yet, most places I've seen the hardware/network support people work harder and are paid a lot less than the programmers... its usually not much better than burger flipping money.
Ouch.
(I worked one place where a friend claimed that before I joined there was a PhD guy from Russia who left his country/industry to work for these guys doing NT printer configuration because it was more challenging than his previous job, which had something to do with the physics of plasma in a vacuum... yes, thats right, a real live rocket scientist says NT configuration and trouble shooting is *harder* than rocket science... :-)
-
Fear
2004-05-05 10:38:23 bblfish
Those are some good observations.
That is why I am now working on Open Source projects. I don't yet get paid, but at least I feel I can grow and learn things at my own pace. Since there is no money involved I can really find out what does motivate me and where my interests lie. That is a great way to reconnect with the spirit of technology. :-)
To get back to the original theme one could remind oneself that it is unlikely that any top surgeon would ever have found the motivation to reach his position - all those years of studies - if it were not for the love he had for his profession.
-
Fear
2004-05-05 10:27:40 johnm
Isn't there some quote about the tyranny of those without power?
"Slaves make the worst masters." --JDM
The people in the examples had no power to effect change, and they were fearful.
"Never underestimate the power of your subjectivity." --DC
Interesting that extremely wealthy individuals are often motivated by something other than money.
"Follow your bliss." --JC
a real live rocket scientist says NT configuration and trouble shooting is *harder* than rocket science.
Rocket science follows the rules of reality. NT configuration and trouble shooting follow the rules of Microsoft. :-)
-
Chapter 3: Bargain Developers?
2004-04-29 21:03:06 rickcarson
Its not just programmers. One of my 'happy places' is the memory of when I (or rather, my design) went head to head with a consultant from Sun.
In 3 days I had talked to the analysts, groked the requirements, and built a proof of concept.
In 3 days, he came up with a radically different architecture/design.... 27 days later though (after the analysts kept coming back with concerns about the proposed design), his design was almost exactly identical to mine :-) (The only difference being an object pool in a place where I didn't think we needed one, but was to minor a point to argue.)
Me 10.
Sun Consultant 1.
Yeah baby. :-)
I *did* learn something from him. Which was that you never use the word prototype in front of the management drones. They don't like it. Instead you talk about 'slices of functionality' (ie exploratory prototyping where you plan to keep the code).
-
Chapter 3: Bargain Developers?
2004-04-30 09:20:27 johnm
:-) Thanks for the lesson!
Do you have any feel for whether the guy was actually incompetent versus ignorant versus padding the bill (or is there something else)?
Was there some reason that the manager(s) allowed this to continue for an entire month instead of cutting it off sooner?
Did you have the whole thing built by the end of the month? :-)
-
Chapter 3: Bargain Developers?
2004-05-04 00:39:37 rickcarson
Incompetent??? WTF??? Heck no!!!!
Sorry for the miscommunication. He was actually one of the best consultants I've ever worked with.
Padding the bill???
Not at all, he was worth every penny (and the pounds too!!) they spent on him.
Why they went with his design instead of mine? Well, its probably a social thing. Like I said, I learned a lot about talking to managers from him. He was really good at communication, and his technical skills were top par...
... and he was from Sun...
... and I'm just a random code monkey ...
Who's design would you go for???
(I'd say his only 'problem' was a fondness for patterns. The problem with introducing patterns too early in the design is that each pattern has consequences - so you end up introducing other problems which you didn't need to have. Part of his background was academic so he did suffer from a little of what Joel calls Architecture Astronauting, whereas I'm *very* OO in how I think about problem solving.)
As a corrollary of another point I made somewhere else, he would be at least 10:1 times better than most programmers when it comes to communicating with management, which is one of the reasons I regret not having the opportunity to do more work with him.
(So long as I get to have a say in the final design :-)
Did you have the whole thing built by the end of the month? :-)
I *was* the first one finished. But given that noone else on the team had ever used Java, I'd be surprised if I wasn't.
I vaguely recall it taking longer than a month, but there was another contractor who was very disruptive - he had a favourite methodology and said that our project would fail miserably if we didn't use it, and he kept trying to take authority away from the team leader and usurp her position (it was his first time as a contractor - I tried to give him some pointers on why that was not good behaviour, but they didn't sink in) and ultimately stormed off (breaking his contract, not sure what the legal ramifications of that were) and things progressed pretty quickly once he'd gone.
There was a particularly ugly backend wrapper for a legacy database which was by far the hardest part of the system to finish. Kudos to the guys that dealt with that bit.
My bit was the middle ware to the middle ware. So mostly what I did was run the test cases which proved that it wasn't *my* part which had broken, and help the other people track down where the problem was in their code.
Given that I'd already had a pretty good poke around in that problem space, yeah, I was finished fairly quickly. :-p
-
Chapter 3: Bargain Developers?
2004-05-04 08:45:35 johnm
Not at all, he was worth every penny (and the pounds too!!) they spent on him.
Sorry for being confused but I don't understand this conclusion given your previous statements about how he basically wasted an entire month. Was his work on other facets stellar or something? For example, was his great communication skills used to bridge the technical with the business for the rest of the project?
-
Chapter 3: Bargain Developers?
2004-05-08 22:28:01 rickcarson
He did do other things of value. Also, just because I'm better at something does not mean that someone else doing it is a waste of time. (though arguably they should have been paying me 10x as much as him... :-)
Eg: have you ever gone to a fast food joint? No doubt you could 'do it better', and yet you pay someone to do a worse job of it than you do...
And I don't often get to 'lock horns' with another designer, I enjoyed the challenge.
And of course with him championing 'his' design, once it got round to where it was pretty close to optimal, I then didn't need to champion it myself. Which let me get on with the job at hand.
And before you ask: an 'optimal' design is one that is a good fit to what you know already, and will adapt quickly to things you are yet to discover...
And if you ask about that, I'll say its a zen thing...
And if you ask about that, I'll just do the dogbert thing, wave my wand at you and go 'bahh!'
;-)
-
Chapter 3: Bargain Developers?
2004-04-27 12:21:10 fredloney
There is at least a 10-to-1 productivity difference, but the catch is discerning who is the 10 and who is the 1. If anything, there is a negative correlation between management perception and actual contribution with respect to developer productivity. E.g. face time and comforting illusions in meetings is often a positive indicator in management perception and negative indicator in actual contribution. Similarly, a developer who quickly dashes off a visually appealing kludge tends to be perceived as productive, whereas the poor chumps who have to live with the consequences of the kludgeware suffer disapprobation. Since management perception determines reward, the conclusion is dismal: there is a 10-to-1 difference, but it doesn't matter.
It is misleading to contrast an offshore team with a "high-quality" team. An offshore team is frequently of comparable quality. Productivity is perhaps another matter, given the communication impediment. Even so, offshoring can be an advantage for a manager incapable of assembling a high-productivity local team. One might as well fumble along at 1/5 the cost with an offshore team.
-
Chapter 3: Bargain Developers?
2004-04-27 17:19:02 johnm
Re: Negative Correlation of managment view with reality
Is your view that it's simply a question of time spent? I.e., that all of the time and energy put into meetings, etc. is the difference. Or is it more than the less competent and/or technically productive folks choose to spend a disproportionate amount of their time in unnecessary, non-technically productive activities so as to e.g., hide their incompetence?
What should managers learn from this? I.e., how can they learn how to really separate the wheat from the chaff? For example, in your example of the developer dashing off a kludge... Where's the feedback from: the rest of the team, the testing and acceptance groups, etc. making it clear to the managers that the person isn't really helping things?
Re: Comparing off-shore teams with "high-quality" local teams
I wrote:
...how is offshoring an advantage over a small, very high-quality team?
That is, there's no bias for/against an offshore team in myquestion. To be clear about my intention, I was trying to ask that people compare the offshore team to a high-quality, local team instead of local but mediocre or poor quality teams.
Now, to your points...
Have you actually, directly worked with an offshore team that you would rate as "high-quality" ? If so, can you elaborate a bit on what you think makes then high-quality? Also, were the project(s) you worked with them on "successful" (i.e., on time, to spec, on budget, etc.)? In particular, how well did the system(s) that the offshore team actually delivered survive through the rest of its/their lifecycles?
Finally, I'm a bit confused by your final statement. If a manager is incapable of building a strong local team then how is that manager going to be able deal with the extra constraints and problems with an offshore team? Or, perhaps, are you switching gears and presuming that the manager, in this case, is strong but literally cannot find high-quality talent locally (perhaps for the penny-pinching prices that the company is willing to pay)? Or something else?
-
Chapter 3: Bargain Developers?
2004-04-26 23:28:22 tackline
I'd guess that around half of developers contribute negatively to a project, so 10 to 1 is a severe underestimate.
-
Chapter 3: Bargain Developers?
2004-04-27 11:23:30 johnm
:-)
Can you elaborate a wee bit more on this "negative contribution"? I.e., I presume you're talking about steady-state degradation rather than them being new members.
Do you find any categories of these detrimental folks? I.e., are some just completely evil while others are just annoying? :-)
Do you find that there's a (big?) group of "break even" developers? I.e., people who are nominally a net positive but just barely (e.g., the '1' in the 10 to 1 equation)?
Finally, what would be the real outcome if we could actually get rid of just the worst 10% or 20% or even 50% of those negative contributors?
-
Chapter 3: Bargain Developers?
2004-04-29 21:37:10 rickcarson
>Do you find that there's a (big?) group of "break even" developers? I.e., people who are nominally a net positive but just barely (e.g., the '1' in the 10 to 1 equation)?
Another place I worked there were a bunch of analysts who were useless. And there were a bunch of programmers who were being retrained in Java (I've seen all sorts - dba's being retrained in Java etc).
The programmers were all nice, well intentioned people, who were all amazing experts with their particular niche products and systems. ...but... That didn't translate to success with Java.
I've seen two people with nearly identical skill sets, from the same town, from the same company, indoctrinated in the same methodologies get told that they are going to become Java programmers... and one of them jumped in and started wading around (and eventually was swimming), the other couldn't even draw on a whiteboard a basic picture of what his part of the app was supposed to do after nearly four months of working on it...
I'm at least 10:1with Java, and with VB before that (way back in the mid 90s). I've worked in places with 70+ developers, and been the only one who put their hand up to have a go at modifying a C++ program (I conducted an informal survey of the other programmers, and most thought that C and C++ were 'too hard').
But... I hate installing things and configuring them. I got so frustrated trying to install Linux that after I 'rm - rf'ed it - I felt so good that I reinstalled it again (with defaults of course) just so that I could have the pleasure of deleting it again.
And I'd never lord it over the plumber, carpenter or mechanic just because I know how to program and they don't - because they can all do things that *I* can't (or won't, or don't want to) do.
I read an example about a kid in the US who was failing maths. But when they asked him about baseball, he could rattle off all sorts of university level statistics about it... and the kid is like 8 or 10 yrs old. He's not stupid, its just that he finds maths boring, and baseball interesting (umm... okay, so I guess thats a contradiction... :-)
Moral of the story:
If you want to change the low productivity programmers into high productivity, find what they like and are good at, and get them doing that (which may free up your 'top guns' from those particular tasks, so that they can do even more 'top gunning').
-
Chapter 3: Bargain Developers?
2004-04-29 21:17:40 rickcarson
There are a number of ways to contribute negatively.
(1) Take up the good developers time. Eg if you have a new developer who needs some hand holding, that takes time away from them being 'productive'.
(2) Overwrite everybody else's changes in the CVS with a copy of the code from the previous day. (I had a lead programmer once who did this. Every day at about 4pm he'd take a complete copy of the cvs. Then he take off for the day, and maybe do a bit of work on the train or at home (he was charging for about 12 hours work a day (even though (or is that because) he had a very young family) - and he'd bill for 20+ hrs in the weekend too...). Then sometime the next morning at work, he'd make a change to a class, go to commit the class, and write back the whole of the cvs. Where I come into the picture is that at about 4.30-5pm every day the testers would come back with a bunch of defects to fix. I'd have a look at the defects, fix most or all of them, test that the changes worked, and then commit the changes to the cvs and go home happy that I'd done a good days work.... Of course the testers would start coming back with the same bugs over and over, and I'd be like... didn't I fix that before? This looks familiar...? And I'd quickly fix it and test it and check it into the cvs... So you can imagine that over time me and the testers are getting more and more frustrated. Guess who the bad guy in this scenario was according to management? Yep... me. Unfortunately by the time we found out who the real problem was, I had neither the ability to shift the negative perceptions already built up, nor the desire to do so...)
One of these is evil, one is the price of doing business. See if you can tell the difference...?
-
Chapter 3: Bargain Developers?
2004-05-12 16:50:16 tackline
(1) is where most of the costs are. When you scale the number of developers working on a project, even if they were all identical, the time spent on communication increases. Not just as a total, but as fraction of each developer day. I'm sure someone should write a book about how the so called "man month" is in fact mythical.
Like (2), bad code also takes up time. Time to understand what was supposed to be going on, rewriting it and dealing with the politics. As an example, despite a process that was set up to prevent any rewriting, on one project without realising it at the time I rewrote everything written by my team leader. He didn't seem to be a happy bunny.
Which leads nicely onto another category of negative productivity available to those with some kind of power: Steam rolling over the rest of the team. That is evil with intent.
-
Chapter 3: Bargain Developers?
2004-04-30 13:23:36 fredjean
(2) has been a big pain in a project where some developers were based in India. They never got training in CVS, and the leads (yes, leads! 3 leads in charge of different aspects of the project) insisted that they kept their working directory on a server in the US. The Indian developers did what they could to be able to work on the code and ended up copying it to their home directory on a local server.
The end result was that big files got overwritten many times until the Indian developers finally started to get a clue. Each time, hundreds of men hours were lost in work getting overwritten and in trying to figure out what was causing this.
-
Chapter 2: Brooks' Law Corollaries
2004-04-15 10:16:58 johnm
A classic corollary to Brooks' Law is to trim the feature list to make a delivery date. First off, how many teams really do that consiously and purposefully?
Also, the fact is that to make hard, fixed dates, features suffer one way or another. I.e., it's clear that all of that overtime, etc. induces the creation of buggier code and the taking of short-cuts. So, since everybody knows this fact, including the end users, why does this dishonest practice continue?
Is there a corollary to Brook's Law that "subtracting manpower from a late software project will make the project less late"? Are the people to be subtracted from the team the developers or rather the various disruptors such as marketing people and "managers"?
-
Chapter 2: Brooks' Law Corollaries
2004-04-20 19:00:59 tackline
I once worked at a company that tried to introduce DSDM. Each feature was classified a Must Have, Should Have, Could Have or Wont Have. Unfortunately the feature set was fixed and the time boxes ignored.
Brooks talks about training time of new members setting the project back. Obviously if you trim the team you wont get back any of the expended effort, in fact they will take some of the group knowledge away with them.
OTOH, the next chapter in the book talks about productivity varying by a factor of ten between experience programmers. If you know who your best and worst programmers are (a very big assumption for managers) then pruning appropriately will allow the rest of the team to be unhindered.
At the same company as above, a project was claimed "code complete" (not as in the book) just to get rid of contractors. Sections of the code then had to be thrown away and rewritten. A high level member of management then talked enthusiastically about getting many more similar contractors in...
-
Chapter 2: Brooks' Law Corollaries
2004-04-21 22:19:35 johnm
I once worked at a company that tried to introduce DSDM. Each feature was classified a Must Have, Should Have, Could Have or Wont Have. Unfortunately the feature set was fixed and the time boxes ignored.
Did they also ignore the feature classification?
Brooks talks about training time of new members setting the project back. Obviously if you trim the team you wont get back any of the expended effort, in fact they will take some of the group knowledge away with them.
Indeed. However, what do you think of approaches such as pair-programming and collective code ownership that help spread knowledge throughout the team?
OTOH, the next chapter in the book talks about productivity varying by a factor of ten between experience programmers. If you know who your best and worst programmers are (a very big assumption for managers) then pruning appropriately will allow the rest of the team to be unhindered.
In terms of the assumption, are you talking about managers having no clue about who's better/worse?
IIRC, there was a case study of a steel company in one of the mid-atlantic states where they "reengineeered" the way that they did raises. Everybody on a team evaluated everybody else. They found that the "quality" improved but the teams were very conservative in giving out raises.
At the same company as above, a project was claimed "code complete" (not as in the book) just to get rid of contractors. Sections of the code then had to be thrown away and rewritten. A high level member of management then talked enthusiastically about getting many more similar contractors in...
LOL! Thanks!
-
Chapter 2: Brooks' Law Corollaries
2004-04-26 23:27:47 tackline
Pair-programming and collective ownership are certainly going to spread out knowledge. As will code review and continuous integration. OTOH there are traps in spreading too thin, no single person having a deep enough understanding of each specific area and wasting time duplicating ten times what can be done twice.
Like programmers, managers vary enormously. Managers that Manage By Walking Around are more likely to have a clue than those that hide in offices handing down directions with selective feedback or are seduced by unrealistic claims.
Appraisal by peers is something that is enthusiastically talked about. I think there is some issue in that it turns the exercise into some sort of game theory exercise. Combine this with the tendency to forget good things said and dwell on the negative, and there's a danger of a spiral.
-
Chapter 2: Brooks' Law Corollaries
2004-04-27 12:11:32 johnm
Pair-programming and collective ownership are certainly going to spread out knowledge. As will code review and continuous integration. OTOH there are traps in spreading too thin, no single person having a deep enough understanding of each specific area and wasting time duplicating ten times what can be done twice.
Indeed. Regardless of the collective ideal, the fact is that people have different skills and passions and so there's usually someone who is the "expert"/"driver"/etc. of any given area. One way to think of that person in terms of an agile/XP team is as the "godfather" of that area. I.e., it's not that you have to run everything through them but rather you have to think seriously about whether or not what you're thinking of doing to their area is going to piss them off so much that you get whacked. :-)
Appraisal by peers is something that is enthusiastically talked about. I think there is some issue in that it turns the exercise into some sort of game theory exercise. Combine this with the tendency to forget good things said and dwell on the negative, and there's a danger of a spiral.
Indeed! All too true! In the example that I mentioned previously, management had to step in to give more raises and promotions than the peers were giving out partly due to the conservatism but also partly do to the creation of cliques/favoritism and the different standards set by different teams (think: grade inflation vs. integrity :-).
-
Chapter 2: Brooks' Law & "Agile" Processes?
2004-04-15 09:55:55 johnm
Brooks' Law: Adding manpower to a late software project makes it later.
How does this jive with development processes such as pair programming which can have an information dispersal effect across a team? I.e., do practices such as pair programming help reduce the pain of absorbing additional team members? At the limit, does that just devolve into a master/apprentice setup or does switching partners make up for it (even though switching has costs, too)?
Do you find that other "agile" techniques, especially ones which involve the customer and the customer vs. developer responsibilities, help to mitigate the all-or-nothing "big bang" style of deliveries? Do those techniques work at all in areas such as games?
-
Chapter 2: Brooks' Law & "Agile" Processes?
2004-04-29 21:55:33 rickcarson
Today one of my other team members bought up that our standards people are pushing for a toolset (for J2EE) which we can't run on our current PCs (our PCs + WebLogic = molten pile of slag).
So our manager said that we might be able to get new PCs - and they would fund it by forcing the developers to pair program so they can take half the PCs away (she was joking... I think... *meep*).
To which I replied that the programmers would start pair programming the minute the managers start pair managing. :-D
On the basis of the evil glare that earned me, I'd say that this year I probably won't be getting a bonus. :-( D'oh!!!
Still, it was very funny. :-)
I think I'm safe - they say here it turns out that for pair programming to work, you need to have relatively equal programmers. Since I got on the Java bandwagon relatively early ('96) I've never met anyone with as much Java experience as me. I know they must exist (Gosling, et al) but have never met one of these semi-mythical beats. So given that they won't find anyone on an equal level, I should be okay. :-)
-
Pair Management
2004-04-30 09:45:56 johnm
So our manager said that we might be able to get new PCs - and they would fund it by forcing the developers to pair program so they can take half the PCs away (she was joking... I think... *meep*).
Please do let me know if that turns out to not be a joke.
To which I replied that the programmers would start pair programming the minute the managers start pair managing. :-D
LOL.
I think one of the most interestingly bad unintended consequence of the technology revolution has been the huge decrease in the number of secretaries. [No, I don't mean that in a sexist way.] Ala the "surgical team" that Brooks' recommends, the old school setup of a "manager" and a secretary had a built-in distinction between the strategic tasks and the tactical tasks.
-
Chapter 1: Programming Systems Product
2004-04-14 22:13:16 johnm
What do you think about Brooks' notion of the "Programming Systems Product"?
Do his categories (program, programming product, programming system, and programming systems product) make sense?
Have you used the 3X multiplier in creating your estimates?
-
Dumb question
2004-04-13 22:17:44 nevster
I kept looking for some link to the book club but am I right in assuming the 'club' is just posting comments to this blog entry?
Maybe you could provide some structure - questions, things to discuss, etc.
-
Dumb question
2004-04-14 11:44:02 johnm
Excellent question! Indeed, this discussion forum is for the bookclub.
Indeed, I'll start stirring the pot a bit later today. I wanted to give people some time to get up to speed before things get too spicey. :-)
-
Welcome to the java.net bookclub!
2004-04-13 11:22:34 johnm
To start things off, we're jumping into Frederick P. Brooks, Jr.'s classic,
The Mythical Man-Month: Essays on Software Engineering. Note that we're
going to using the 20th anniversary edition since that has goodies such
Brooks' famous paper No Silver Bullet -- Essence and Accident in Software
Engineering.
It's been 40 years since the creation of the landmark IBM System/360 with its
OS/360 operating system. Almost 30 years have passed since Brooks published the
first edition. Intriguingly, Java's public lifespan conincides nicely with the
release of the 20th anniversary edition of The Mythical Man-Month in
early 1995.
In some ways, a lot of things have changed both subtly and dramatically since
then but, it seems to me that very little of the fundamentals have changed at
all. I am honored to explore the many wondrous facets of this paradox with all
of you.
Enjoy,
John
-
Virtual bookclubs...
2004-04-14 17:09:07 melriffe
I look forward to participating in this bookclub. The initial selection is spot on; too often I find I forget the lessons of the past, or more precisely, I forget to benefit from someone else's mistakes/experiences.
Might I suggest one possible format/structure for this bookclub: reading assignments. I look forward to reading everyone's thoughts and anectodotes related to Mythical Man-Month as much as I look forward to re-reading the essays.
Good luck and happy reading...
Mel
-
Welcome to the java.net bookclub!
2004-04-14 15:07:17 fredjean
I would say that the basic tenets of The Mythical Man-Month still hold true today. They are even further amplified with geographically distributed work teams with developers in different time zones.
It is difficult to communicate properly when it could take up to 18 hours for someone's response to reach you.
Frederic Jean
-
Locality?
2004-04-14 22:06:16 johnm
Hmm... Are you advocating only having teams that are co-located?
-
Locality?
2004-04-27 10:42:13 fredjean
No. It would be nice to have a co-located team, but it would be unrealistic to expect this to happen. One of the beauty of globalization is that you can go get talented individuals on your team no matter where they are located.
Dispersed team can be effective. IM, email, conference calls and video conference calls help greatly to communicate.
Sometimes communications do break down. Here's an example.
I am currently working on a set of web services for an internal application. One of the tools that interfaces with this service is developed in France. There is only a couple hours of overlap between the France business day and the US business day. A developer would send me an email. By the time I was done with morning meetings, the developer in question was headed home. If I had a question, I wouldn't get an answer until the next day.
This was eventually resolved through scheduling conference calls early in the morning.
-
Locality?
2004-04-27 11:32:16 johnm
Cool, thanks. My brain's notion of what time it is is definitely different since working with people in Europe, America, and Asia simultaneously. :-)
Do you find that different types of developers work better/worse in a co-located vs. a distributed team? I.e., does it take a certain kind of person (and/or process and/or organizational culture) to succeed in a distributed team?
-
Locality?
2004-04-15 08:51:34 vdeep
It some times takes more time for a co-located team to respond. We are here a team across 4 states and respond to every thing immediately. It all depends....on how the team/organization is structured and the culture of the company.
-
Locality?
2004-04-20 19:04:41 tackline
Certainly I've had no problem bouncing messages to and throw to colleages on the West Coast (from the UK). But then it can be difficult getting responses from someone within spitting distance. It's certainly a culture/personality thing.
-
Locality, for granted?
2004-04-21 21:53:03 johnm
Do you chat via email with the local people much or is there a bias ? I.e., do you think that people take proximity for granted. For example, it seems like a truism that people who live in a big, touristy city only go to the tourist attractions if they are forced to by visiting friends or relatives.
-
Locality, for granted?
2004-04-26 23:31:03 tackline
I'd tend to use e-mail locally only for asynchronous notification in a bureaucracy, transferring files or information that needs to be exact, and in extreme cases something I want recorded. I wouldn't want to chat by e-mail, or comment on a web page, to someone I could have a coffee with. However, I once visited a company that used a mud to chat between offices in the same building, which kept everyone informed and saved on going up and down the stairs.
|
Showing messages 1 through 146 of 146.
|
|
java.net RSS Feeds
