Actually, outside of the discussion of architect vs. developer, Brooks doesn't address "managing seasoned programmers" a lot, which was the poster's question.
As you can see from this article and from this list, I have a lot of books I can recommend for IT management in general, starting with "The Mythical Man-Month"...bruce..
First, read Gerry Weinberg's classic work, "Becoming a Technical Leader". It's particularly apt for you, since you've transitioned from being a developer to being a manager.
Finally, work your way through "Journey of the Software Professional: The Sociology of Software Development" by Luke Hohman. This book deserves to be far better known (and read) than it is. It's a denser book than the first two, but will cover virtually every issue that you'll run into as a software project manager...bruce..
Disclaimer: I am not a lawyer and this is not legal advice. So, yeah, get a really good lawyer and get some good legal advice before you do anything.
Over the past 10 years, I have served as an expert witness in a number of IP-related software lawsuits, many of which have a fact pattern pretty much identical with what you've laid out.
Yes, they can sue you on (at least) two different grounds: copyright violation and theft of trade secrets.
The case Computer Associates v. Altai established the concept of non-literal copyright infringement of source code. Even if you rewrote the program from scratch in another programming language, the AFC ("abstraction, filtration, comparison") test could be used to find similarities, and your (former) employer could argue copyright infringement, not just on source code grounds, but on architecture, design, database schemata, and data file structure.
Even if you go one step farther and use a "clean room reverse engineering" effort to rewrite the code, you could still be sued (and lose) for theft of trade secrets. Your employer would need to identify those trade secrets, show what steps it took to protect its trade secrets (typically such actions as IP and/or confidentiality agreements, some measures of physical and electronic security, etc.), and argue for the value of those trade secrets. You would have to show that those "trade secrets" can be documented outside of their history at the company you're leaving.
Note that if any one of your group of "good friends" is seen as having a significant position in your large software company, they can also try to come after you for "breach of fiduciary duty".
In any case, they might well name each of you individually as defendants along with whatever new company you set up to develop this software.
In short, there are major risks to what you are describing and not a lot of upside without an explicit release. It can be done, and done successfully, but lawsuits are expensive...bruce..
When I submitted this story, I gave it the headline "US Court:...". Someone changed that to "PA Court Says...". That's wrong. This is a ruling from a US District (Federal) court, not a Pennsylvania state court, and so carries much more weight...bruce..
I first used the p-System in 1981 on a Northstar microcomputer at the Lunar and Planetary Institute to write an HP graphics terminal emulator for a Houston Instruments large-bed plotter. I was having problems with the p-System (with floating point calculations, no less) and so ended up writing a p-code disassembler so that I could figure out what was going wrong. I came up with some solution, though I don't remember what it was.
The disassembler came in handy a few years later when I ended up writing SunDog: Frozen Legacy for the Apple II using Apple Pascal. I extended the disassembler into a full 6502/p-code disassembler and disassembled the entire Apple Pascal system so that I could put hooks into it (basically implemented an event loop that would test-and-lock on button-up and button-down). The Unit capability (user memory management) was critical, since the whole game was running -- with the p-System and the p-code interpreter -- in 64KB of RAM. I knew every byte of that Apple II/Apple Pascal memory map....
When FTL Games ported SunDog over to the Atari ST after I left FTL, they used the UCSD p-System over there and so were able to bring over large portions of the source code intact.
But, no, I never ported the p-System itself.:-)..bruce..
My first thought on reading this was an old software engineering maxim, usually (and probably correctly) attributed to Don Knuth:
There is no complexity problem in programming that cannot be eased by adding a layer of indirection. And there is no performance problem in programming that cannot be eased by removing a layer of indirection.
Universal VMs are old as the hills (anyone [else] here old enough to have programmed on the UCSD p-System?). We shift towards VMs to gain independence and portability, and then we shift back to direct, spot or JIT compilation to improve performance. It's an old, old dance, and one that will likely go on for years to come...bruce..
Back when I was fresh out of college (graduated in 1978), I found myself constantly having to learn new operating systems (mostly mainframe and minicomputer), new editors, new compilers (and languages), and so on. Heck, in my first year out of college, while at General Dynamics/WDSC, I worked on four different computers (CDC mainframe, Perkin-Elmer minicomputers, a Harris hybrid analog/digital computer, and some other mini-computer that I can't remember at the moment -- other than that I could tell what stage the compilie/link process was in by the noise the hard drive [5 MB and occupying a box the size of a 2-drawer file cabinet] was making).
So, one of my 'coming-up-to-speed' techniques was to write a program that interested me. In this case, I wrote a program that would randomly roll up and print out D&D monsters and NPCs, complete with stats. By the time I had that program working, I pretty much knew how to use the system and how to do software development on it. I think I still have some of those printouts in my files at home...bruce..
I'm only semi-facetious in saying that. I never liked puzzle games because (a) they pretty much require that you read the game designer's mind, and (b) they are almost always what my co-designer Wayne Holder called (derisively) "railroad games" -- that is, you're stuck on the tracks and you can't get off. Also, (c) the "puzzles" are often pretty arbitrary, having little to do with the game itself.
But in the early days of computer games (and my own days go back to the early 1980s), puzzles were a cheap form of complexity precisely because graphics, UI and presentation were so hard and consumed so much of the limited resources.
I frankly think that most "modern gamers" are heaving great sighs of relief at being rid of "puzzle games" and being able to play something else for a change. But that could just be me...bruce.. (co-author, Sundog: Frozen Legacy)
Apologies for not looking closer. The original New Scientist article was just about the Jonason study out of New Mexico State University. Your own criticisms of the Schmitt study study are very relevant, as is the simply issue again of: how do you verify that the claimed level of sexual activity actually took place, when these people are probably the ones most likely to lie about it?..bruce..
Uh, there are serious problems with this study, most notable that it relies upon self-reporting of sexual activity by at most a few dozen or so college-aged males (the total sample size is 200 men and women) who rank high in narcissistic, psychopathic, and manipulative behavior. Anyone else think there may be a problem with that?
Ironically, the lead author of this study has another one coming out entitled, "The power of prestige: Why young men report having more sex partners than young women."
If I have less than warm feelings towards Heathkit, it's because almost 30 years ago, while working at the Lunar and Planetary Institute, my boss (a great guy, BTW) decided to save LPI some funds. Rather than buying assembled terminals to use with our new VAX, he instead bought quite a few Heathkit dumb CRT terminal kits and then paid me (per terminal) to assemble them after work hours.
It did save LPI money, and it put some extra money in my pockets -- but as I type this, I can feel again the burns and cuts on my fingertips from hours upon hours of assembling and soldering, not to mention the general frustration at trying to make each terminal work (which I did, eventually). I can't remember how many terminals I built, but I know the VAX was intended to support 30 LPI personnel, so it was a lot.
Mostly, it reinforced my earlier decision back in college to be a CS major, rather than a EE major.:-)..bruce..
Heh. I have actually written several memos/report for troubled projects, but they've all had quite different organization and content. Besides, I always go in as an optimist -- "can this project be saved?" Some can (and are), but others get stuck in that limbo of pouring more money down the rat hole until someone sufficiently high up gets the nerve to pull the plug...bruce..
Yeah, from what I read the FBI project blew through $150 million or more, only to be told that there wasn't anything useful to be gained out the work that had been done.
Hadn't heard about McDonalds; I'll have to go digging for information on that one...bruce..
Normally, I'd just tack on comments onto the post on my blog -- but given the server problems I had through most of the day, I thought I'd come and comment here.
Besides -- I stand behind what I write. Who did you say you were again?:-)..bruce..
Yep. What you said.:-) I happen to be writing a book (Pitfalls of Modern Software Engineering), which is a greatly expanded version of a book I previously wrote and published (Pitfalls of Object-Oriented Development, M&T Books, 1995). I'm posting the revised pitfalls, a few at a time, on another website (see here). Many of these pitfalls are clearly political ("Picking the wrong horse") and are labeled as such...bruce..
Assuming that "TFA" refers to the memo I posted, I think you're confusing the audience and scope of it the memo. This was for a senior, technically-oriented executive who was concerned over the gap between the optimism that was being reported upwards to him/her and the constant schedule and budget overruns that had been a reality for (by this point) a few years.
The memo was never indented to be a close-detail, point-by-point listing of existing flaws in the project; for starters, that probably would have filled a few binders at least. A request for such a review would be the natural follow-up by the senior executive; it would likely take at least a few months. (I have done that kind of review, though not for this project.)..bruce..
I had to run errands for an hour or so and came back to discover that my server appeared to be completely crashed and had been so for over an hour. It's back up now...bruce..
You're confusing the reality ("Many of the people...") with what BigFirm management was telling itself about the project ("The FUBAR project..."). That was one of the real problems -- upper management had been led to believe that BigFirm really did have a "world-class development team" when they had anything but that...bruce..
Slashdot Mirror
Actually, outside of the discussion of architect vs. developer, Brooks doesn't address "managing seasoned programmers" a lot, which was the poster's question.
As you can see from this article and from this list, I have a lot of books I can recommend for IT management in general, starting with "The Mythical Man-Month". ..bruce..
First, read Gerry Weinberg's classic work, "Becoming a Technical Leader". It's particularly apt for you, since you've transitioned from being a developer to being a manager.
Second, read "Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister. Still the single best work on shaping and managing software teams.
Finally, work your way through "Journey of the Software Professional: The Sociology of Software Development" by Luke Hohman. This book deserves to be far better known (and read) than it is. It's a denser book than the first two, but will cover virtually every issue that you'll run into as a software project manager. ..bruce..
Disclaimer: I am not a lawyer and this is not legal advice. So, yeah, get a really good lawyer and get some good legal advice before you do anything.
Over the past 10 years, I have served as an expert witness in a number of IP-related software lawsuits, many of which have a fact pattern pretty much identical with what you've laid out.
Yes, they can sue you on (at least) two different grounds: copyright violation and theft of trade secrets.
The case Computer Associates v. Altai established the concept of non-literal copyright infringement of source code. Even if you rewrote the program from scratch in another programming language, the AFC ("abstraction, filtration, comparison") test could be used to find similarities, and your (former) employer could argue copyright infringement, not just on source code grounds, but on architecture, design, database schemata, and data file structure.
Even if you go one step farther and use a "clean room reverse engineering" effort to rewrite the code, you could still be sued (and lose) for theft of trade secrets. Your employer would need to identify those trade secrets, show what steps it took to protect its trade secrets (typically such actions as IP and/or confidentiality agreements, some measures of physical and electronic security, etc.), and argue for the value of those trade secrets. You would have to show that those "trade secrets" can be documented outside of their history at the company you're leaving.
Note that if any one of your group of "good friends" is seen as having a significant position in your large software company, they can also try to come after you for "breach of fiduciary duty".
In any case, they might well name each of you individually as defendants along with whatever new company you set up to develop this software.
In short, there are major risks to what you are describing and not a lot of upside without an explicit release. It can be done, and done successfully, but lawsuits are expensive. ..bruce..
What, do they watch old Saturday Night Live episodes? ..bruce..
You're speaking to a published writer -- that hits a lot closer to home than you may realize. :-) ..bruce..
When I submitted this story, I gave it the headline "US Court:...". Someone changed that to "PA Court Says...". That's wrong. This is a ruling from a US District (Federal) court, not a Pennsylvania state court, and so carries much more weight. ..bruce..
I first used the p-System in 1981 on a Northstar microcomputer at the Lunar and Planetary Institute to write an HP graphics terminal emulator for a Houston Instruments large-bed plotter. I was having problems with the p-System (with floating point calculations, no less) and so ended up writing a p-code disassembler so that I could figure out what was going wrong. I came up with some solution, though I don't remember what it was.
The disassembler came in handy a few years later when I ended up writing SunDog: Frozen Legacy for the Apple II using Apple Pascal. I extended the disassembler into a full 6502/p-code disassembler and disassembled the entire Apple Pascal system so that I could put hooks into it (basically implemented an event loop that would test-and-lock on button-up and button-down). The Unit capability (user memory management) was critical, since the whole game was running -- with the p-System and the p-code interpreter -- in 64KB of RAM. I knew every byte of that Apple II/Apple Pascal memory map....
When FTL Games ported SunDog over to the Atari ST after I left FTL, they used the UCSD p-System over there and so were able to bring over large portions of the source code intact.
But, no, I never ported the p-System itself. :-) ..bruce..
My first thought on reading this was an old software engineering maxim, usually (and probably correctly) attributed to Don Knuth:
Universal VMs are old as the hills (anyone [else] here old enough to have programmed on the UCSD p-System?). We shift towards VMs to gain independence and portability, and then we shift back to direct, spot or JIT compilation to improve performance. It's an old, old dance, and one that will likely go on for years to come. ..bruce..
Back when I was fresh out of college (graduated in 1978), I found myself constantly having to learn new operating systems (mostly mainframe and minicomputer), new editors, new compilers (and languages), and so on. Heck, in my first year out of college, while at General Dynamics/WDSC, I worked on four different computers (CDC mainframe, Perkin-Elmer minicomputers, a Harris hybrid analog/digital computer, and some other mini-computer that I can't remember at the moment -- other than that I could tell what stage the compilie/link process was in by the noise the hard drive [5 MB and occupying a box the size of a 2-drawer file cabinet] was making).
So, one of my 'coming-up-to-speed' techniques was to write a program that interested me. In this case, I wrote a program that would randomly roll up and print out D&D monsters and NPCs, complete with stats. By the time I had that program working, I pretty much knew how to use the system and how to do software development on it. I think I still have some of those printouts in my files at home. ..bruce..
No, no, I heard it was Microsoft Cloud Server 2008 Enterprise Edition. ..bruce..
I'm only semi-facetious in saying that. I never liked puzzle games because (a) they pretty much require that you read the game designer's mind, and (b) they are almost always what my co-designer Wayne Holder called (derisively) "railroad games" -- that is, you're stuck on the tracks and you can't get off. Also, (c) the "puzzles" are often pretty arbitrary, having little to do with the game itself.
But in the early days of computer games (and my own days go back to the early 1980s), puzzles were a cheap form of complexity precisely because graphics, UI and presentation were so hard and consumed so much of the limited resources.
I frankly think that most "modern gamers" are heaving great sighs of relief at being rid of "puzzle games" and being able to play something else for a change. But that could just be me. ..bruce.. (co-author, Sundog: Frozen Legacy )
Apologies for not looking closer. The original New Scientist article was just about the Jonason study out of New Mexico State University. Your own criticisms of the Schmitt study study are very relevant, as is the simply issue again of: how do you verify that the claimed level of sexual activity actually took place, when these people are probably the ones most likely to lie about it? ..bruce..
Uh, there are serious problems with this study, most notable that it relies upon self-reporting of sexual activity by at most a few dozen or so college-aged males (the total sample size is 200 men and women) who rank high in narcissistic, psychopathic, and manipulative behavior. Anyone else think there may be a problem with that?
Ironically, the lead author of this study has another one coming out entitled, "The power of prestige: Why young men report having more sex partners than young women."
I rant about all this a bit more here. ..bruce..
If I have less than warm feelings towards Heathkit, it's because almost 30 years ago, while working at the Lunar and Planetary Institute, my boss (a great guy, BTW) decided to save LPI some funds. Rather than buying assembled terminals to use with our new VAX, he instead bought quite a few Heathkit dumb CRT terminal kits and then paid me (per terminal) to assemble them after work hours.
It did save LPI money, and it put some extra money in my pockets -- but as I type this, I can feel again the burns and cuts on my fingertips from hours upon hours of assembling and soldering, not to mention the general frustration at trying to make each terminal work (which I did, eventually). I can't remember how many terminals I built, but I know the VAX was intended to support 30 LPI personnel, so it was a lot.
Mostly, it reinforced my earlier decision back in college to be a CS major, rather than a EE major. :-) ..bruce..
ROLF! Actually, when I came up with "Winsom" I was thinking of "winsome"...at least consciously. I think I like your interpretation better. ..bruce..
Heh. I have actually written several memos/report for troubled projects, but they've all had quite different organization and content. Besides, I always go in as an optimist -- "can this project be saved?" Some can (and are), but others get stuck in that limbo of pouring more money down the rat hole until someone sufficiently high up gets the nerve to pull the plug. ..bruce..
Yeah, from what I read the FBI project blew through $150 million or more, only to be told that there wasn't anything useful to be gained out the work that had been done.
..bruce..
Hadn't heard about McDonalds; I'll have to go digging for information on that one.
Normally, I'd just tack on comments onto the post on my blog -- but given the server problems I had through most of the day, I thought I'd come and comment here.
:-) ..bruce..
Besides -- I stand behind what I write. Who did you say you were again?
Actually, truth tends to die above the thermocline. It's the folks in the trenches who usually have the best idea as to what's going on. ..bruce..
Gary:
:-) I happen to be writing a book (Pitfalls of Modern Software Engineering), which is a greatly expanded version of a book I previously wrote and published (Pitfalls of Object-Oriented Development, M&T Books, 1995). I'm posting the revised pitfalls, a few at a time, on another website (see here). Many of these pitfalls are clearly political ("Picking the wrong horse") and are labeled as such. ..bruce..
Yep. What you said.
Yep -- time to flesh out those topics. Watch the skies! ..bruce..
Assuming that "TFA" refers to the memo I posted, I think you're confusing the audience and scope of it the memo. This was for a senior, technically-oriented executive who was concerned over the gap between the optimism that was being reported upwards to him/her and the constant schedule and budget overruns that had been a reality for (by this point) a few years.
..bruce..
The memo was never indented to be a close-detail, point-by-point listing of existing flaws in the project; for starters, that probably would have filled a few binders at least. A request for such a review would be the natural follow-up by the senior executive; it would likely take at least a few months. (I have done that kind of review, though not for this project.)
I had to run errands for an hour or so and came back to discover that my server appeared to be completely crashed and had been so for over an hour. It's back up now. ..bruce..
You're confusing the reality ("Many of the people...") with what BigFirm management was telling itself about the project ("The FUBAR project..."). That was one of the real problems -- upper management had been led to believe that BigFirm really did have a "world-class development team" when they had anything but that. ..bruce..