On March 7, 1992, a little-known Finnish software developer called Linus Torvalds issued version 0.13 of his open source operating system as version 0.95. It was a bold move, which took place (according to the FAQ) because "Linux is very close to a reliable/stable system". By moving the numbering system from incrementing from …
Dreaming in Code
> developers, if allowed to innovate in a structured fashion, will get to an answer faster...
"structured" being the key word. Go read "Dreaming in Code" - the more "awesome" the developers, and the more free rein you give them, the more out of control they'll be. Five, six years for that poxy little Calendar app that half a dozen of the world's finest software gurus set to work on? A couple of brainy grads could have done it in six months.
Inmates CAN run the asylum
On my last real job (before going independent), I was the lead programmer at a startup. Five to seven people worked feverishly for 18 months to design the premier products of this company and build the first few pilot projects. The CTO was almost always away selling or doing pilots. Once every week or two, when he came by, we'd all crowd into his office for a planning meeting. My main role as software lead was to remind people of what they agreed to in the meetings, and help them work around obstacles in the CTO's absence.
The products shipped around Christmas 2002. The investors kicked in more money soon after, and by March we had a new management team that proceeded to run the place into the ground.
Oh Manager wherefore art thou?
Hmm, yes management would be nice I remember something like that from the 1980's. Since then the IT world seems to have been blighted by an almost total absence of management.
Much of those wandering this It microcosm of industry these days, and purporting to be 'managers', seem to have small abilities in the field of management. In fact arguably any field of note, all to often working as technical staff for these fellows, one hears the quote ' ah umm don't understand that is far to technical for me'. Which is strange really because this was from people whom's role was technical project managers, and the depth of technicality required would be ordering a few tapes for a tape drive.
I personally attribute a lot of this to the idiots employed in the years on the run up to the year 2000. As the apparent need for IT staff increased almost anybody who either could spell IT with say an 'i' and a 'T', or perhaps stood in the right bus queue in the Thames Valley, could get a job as a Y2k consultant.
Many of these folks produced stunning reports on the process for addressing the Y2K problem, not the actual solution mind, but plenty of process. The reports were indeed stunning in that if they fell from the shelf where they had eventually come to roost, they would at least stun, if not fracture your skull. In summary however the report said nothing more than :
a. hmm, you have a problem with Y2K, here is your answer
b. make a list of all your computer systems (now here comes the cunning science bit)
c. put the real important ones at the top,
d. keep adding systems until ...
e. the least important at the bottom is last
f. TEST & FIX the ones at the top of the list first
And so gentle reader these oxygen thieves were left to return to their previous world .... breaking news ........ unfortunately this did not seem to happen. Along with ITIL, ISO9001, and sundary other pieces of c**p, these Windows Solitaire analysts had by then acquired credibility, and stayed on. I guess the pay was better than geting a PI Giro, or pinching radios from cars.
Since then, one (oh alright I ain't the queen), I have worked places and encountered management examples, such as -
a. in a survey of our managers 38% did not want to mange people. This organisation is now outsourcing (not really sure why, but I'm sure they will love it). Hearing this comment I muttered quietly at the time to a colleague 'so what the f*** do they want to manage, penguins, or maybe desk fluff'.
b. the sublime personal management of working till 11:00 at night recovering a VMS system, being told to come in for 7:00 this next morning (sure this against some sort of EC or HSE rule). Getting in for 7:00 in the morning. Fixing the VMS system about 10:30. Only to find that I was supposed to go to a team meeting at 9:30, which el manager had sent an email on about 2 months previously, and then receiving a right good telling off. The managers PA had also been told off for attempting to go round, and let us know that we was supposed to go to the meeting. Apparently 'we didn't need spoon feeding, and should remember these things'. Could just be Sleepless in Seattle, or is that Settle.
c. organisations that now have more 'managers' than staff. What are they all for? As an indicator of these sort of places look at the CC list on an email, if there are 50 or so names on this, then the company you work for has a few too many managers.
d. the project manager who was recruited as a futures business specialist for the project on which I was working. It was a bit of a surprise to discover my knowledge of futures trading, based on reading a book (a couple of chapters in fact), and chatting to a mate at lunch, exceeded el project manager.
Hmm better stop ranting now. Just for the record the phrases, 'Flotsam and Jetsam of Y2K', and 'Oxygen Thieves' are not mine. Then again since I am posting anonymously I probably better not give a citation.
Perhaps I am just getting old, and am now noticing what has been described as one of the problems with British Industry.
I guess Software Developers shouldn't (ideal world) but either (real world) might as well or just do manage themselves. (Lord knows if the commas are the right place here, actually this is pretty much solicitor English, and that could be a whole new rant :-)
Finally to all those too few managers who do a good job, keep at it, Carpe diem, or even better Carpe cerevisi!
Running code ...
Running code trumps all abstract argument.
We can babble acronyms and buzzwords all we want, but I suspect we'd have better luck understanding the subject at hand if we take an in-depth look at the management of several successful FOSS projects.
Start with the Linux kernel, Apache, MySQL and Perl (PHP, Python). Throw in Sendmail, INN, KDE, Mozilla, the GCC compiler suite, Emacs and Gimp (in no particular order, add your own handful or three to round out the package).
Compare and contrast what they have in common. Ignore the differences. I might actually do this, when I get a spare week or two ... The results would probably prove not just interesting, but useful ...
 I can't remember where I first read that, probably 20+ years ago on Usenet.
Some managers are very good
But in my experience most are micro managing freaks
I was part of a 2 man team writing software for a major chain
Progress was rattling along, then some muppet decided we needed a manager, previously we reported straight to the board.
He came in and trashed everything we were doing, work stopped (due to complete lack of morale), and we both quit within months.
Pity, as the system was 99% complete, did everything it was required to and was stable.
We were not even able to demo the latest version to the MD as it sometimes crashed, and micro managing freak didn't like , so we had to demo a rollback which was missing a lot of vital features, we knew what the result would be, MD was not happy. If we'd demoed the latest version he would have seen the program nearly ready.
Mines the one with the self employed badge on it.
I will NEVER take such shit from management again.
It's all relative
A managers job is to help the developers to work as productively as possible towards logical and acheivable project goals by protecting the team and earning their respect by fighting heroically for them against the boneheaded stupidity to be found in swampy stagnant meeting rooms across Britain.
Basically the developers PA, gofer and sacrificial lamb...
I found myself nodding my head in agreement...
The only 'big' company (>1000 worldwide emps) I've ever worked for that managed developers well, got products/bug fixes out the door ahead of schedule was managed by an ex-coder with a 'personality' who could fight his own corner in the boardroom and kept the sales/marketing types well away from the developers, apart from the monthly 'meet the developers down the pub' meeting. He was a god in my younger 'fresh out of uni' days. In fact the software we developed in those heady days was still being sold 10 years after we developed it! (No freakin' Y2K bugs here, sonny!)
I was shocked when I entered the world of what is the 'real' big company development mentaility - 2 hour meetings of flip charts and corporate waffle from brown nosing wastes of space desperately trying to get a VP status and very little development getting done. As a contractor in one these hell holes (I put my extortionate rate down to 'boredom money') I was actually told I couldn't deliver a project early - because it would break the milestones! I was still getting paid, but WTF? It's a matter of professional pride!
I believe the rot in the I.T industry set in before the Y2K bug, the explosion of the PC onto the desktop circa 1988 onwards meant more programmers were needed, but there weren't enough to go round, so wages rocketed (£50ph as a contractor back then - those WERE the days) - then I.T. was seen as 'the' job to have.... for the money. Unfortunately this brought a load of talentless money grubbing numpties onto the scene who didn't know a byte from a nibble and the 'Useless money grabbing I.T. bod' generation was born.
Young developers are best managed by older developers (real developers, who are still coding - not the 'failed junior programmer moved to management 'cos we can't sack him' tools) who are managed by a 'developer with a personality' who can talk business to the board. That's programmers nirvana!
Apologies for the long waffle, I obviously needed to get it off my chest. I'm off to slap a couple of junior programmers now...
If No Managers
Then who has to take the heat when things go wrong :p
Seriously though - there is no right answer about management requirements as some people/teams are able to produce the goods without management - others require various levels of management to keep them on track.
A good manager though will already understand this and treat people accordingly - trouble is a lot of them haven't really got a clue about how to manage or what a software project requires
Mine's the one with the evidence the manager said to do something he now claims he didn't
mmmm sausage rolls..
"I remember, back in the day, one chap writing a programme to decide who should go down to the sausage roll machine at break time"
This man deserves all the free sausage rolls he can consume!
@Oh Manager wherefore art thou?
Too bloody right! I agree completly, so much so that I have nothing else to say.
That is all.
Herding Cats indeed
In established professions like engineering and accounting, to manage the project you have to be a member of the profession.
In most countries, to be a partner in a professional consulting firm, you have to be a member of the profession.
It is one of the problems facing IT, that our projects are run by professional salespeople, professional lawyers, and professional accountants. These people know a piece of the puzzle, but they should be resources that an IT professional manager consults. They should not be quarterbacking projects and people they don't understand.
Witness EDS's "herding cats" video. To managers who don't know what they are doing, running an IT project seems like herding cats.
Good management = yes
Good management is a good thing, bad management is worse than no management. I agree with the manager nirvana described above - the one who lets you get on with your job and then fights your corner for you when the inevitable merde strikes le fan. But sadly I'm all too familiar with the "why have you done this? erm, because you told me to" management scenario.
I work in a company where people get promoted to manager moreorless by default... i.e., if you've worked there long enough. Management roles pretty much get invented purely 'cos the Directors, I don't know, feel obliged to promote someone for doing their job. It's utter cack.
The net result of bad management is workers who don't put any heart in to their work - they turn up, do their 8 hours, leave on the dot and collect their pay cheque. Very few people have the balls to actually doing anything about a crappy work environment (myself included) so I shouldn't really moan, except gradually my temper gets shorter and shorter that when the idiots 'above me' get in my way, I've got no issue barking at them. I guess I'll either get flagged as an 'up and comer, whose not scared to speak his mind, we like that' or 'troublemaker'. Sometimes I think they'd be doing me a favour if they sacked me, but while I'm getting that cheque, I ain't going anywhere.
AC in case my useless peers actually keep abreast of the tech field by reading publications such as this.
I'm not sure what is a good manager for developers
.... but I'm pretty sure that the company I work for solved that problem long ago. Just outsource all development. While the skill levels within the developers were not very good, save for a few really brilliant people, the developers there never pushed for any new technologies or methods, just were mostly trying to keep their seats cold.
I know that because I joined the company as something of a radical new star that knew about new technologies and could make effective use of them in the business. The developers there were just amazed at what I could accomplish, if only they would invest the time to learn...
Unfortunately, after the outsourcing deal they discovered that, in addition to not having specially brilliant developers, the business community were using software as their vehicle to realize their power games, so the deliverables were not really important. What was important was that you got your own system, or your own little corner on a system to rein in.
Me, I'm the project manager trying to get any value of an outsourcing deal done with the financials in mind more than anything else. What we have now is developers that have no commitment to company values, have technical knowledge and skill levels below the minimum expected or required and a business that is loudly complaining that they are not being properly supported. And a backlog of developments and change requests that is easily three times bigger than before outsourcing.
cos we can't sack him
"failed junior programmer moved to management 'cos we can't sack him' tools"
We get those in Canada too. Any IT manager in Canada with an IT background is either a failed junior programmer or the product of affirmative action -- promoted to supervise and coach those doing jobs they couldn't or haven't themselves mastered.
I would guess in Canada, 75% of higher level IT managers are all salespeople (top title CIOs), with 20% being accountants (top title VP IT), and maybe 2% having any successful IT programming background.
In the hardware side of things you see engineers. I haven't worked in hardware, so I don't know how those companies are managed.
I've had few good managers in all my time. Almost all were bad. Not necessarily bad people, just bad managers but a couple were sociopathic and that's not nice to have around you.
I had one (not one of the psychos, just a twat) who - I'm not kidding - got in a huff when he thought I'd disagreed with him (I hadn't) and tried to stare me down, like a kid in a playground. Tried that a couple more times, too. Just weird. He couldn't cope with anything except full agreement and as he couldn't get me to suck up to him he sacked me. Despite my exceptional record of achievements I was out.
But back to real management, most can't and if you find one that can, you are blessed.
@Anonymous Coward Posted Monday 13th October 2008 23:23 GMT
Sounds to me like you could well be one of the managers we are talking about!
sorting trash into piles
I tend to think of management as a heapsort on a bunch of random numbers. If you have a large pool of managers, over time some will randomly make good decisions and some will make bad decisions. Promotions will ensue, but except for a few very bright managers that do their homework and pay attention, most will just revert to being right just half the time, but now they are higher up in the organization and feel empowered to tell you what to do even though they have no particular insight.
If good Management then Yes, else NO
A good manager keeps the devs shielded from crazy non-sensical requests and other managers that don't understand the importance and priority of the items being made.
At the end it all boils down to working code that will actually make the end-users more productive then they were before, by saving time/money and effort.
For example say we have a request from a user. They want to save two buttons clicks to print an item; They currently must go Export->File-Print->Paper but they don't like that... they want Print->Paper
So the devs go on their way and spend a week or two coding that function up for each report page.... a waste of resources.
Just tell the user no they can't have dumb stuff like that. A bad manager will let coders automate functions that monkey's can do in a fraction of the time.
Save the fluffy features for phase 20 :)
Devs should spend their time adding real value that the company will gain the most from; not making joe-print-boy's life a fraction easier.
A managers job is to balance between what is best for the company, for the devs and for the users; you can't just pick one, all that will do is run the company into the ground in time.
I have seen bad companies and good ones, the difference so far is mostly the quality of the QA department. (IE if you don't have one, you stand a good chance of being a bad company)
Their job is to keep the Software running according to spec, this will keep the Devs in check automatically, they also shield the Dev's from time-wasting bug fix requests by prioritizing the important stuff first and assigning it to the correct team/dev.
If the QA is getting buggy software then the manager should be able to see this.
When there is a problem with something that they are managing,
the first they must do is look at -->themselves<--
It's a Venn diagram thing
Usually, managers in high-tech industries have to have a good level of technical understanding themselves. Lots of people have already pointed this out and it's certainly true in my organisation - the best ones have all done the job at some time in the past and have usually done it well.
The problem is that the intersection of people who really know the tech *and* have people skills *and* are good organisers *and* can handle a bit of stress *and* are suitably thick-skinned is rather small.
I am fortunate enough to work with several like that, but it is a huge organisation and they are definitely not in the majority. If you find one, pay him or her whatever it takes, because they are rare creatures.
Methinks perhaps the problem is not with managers per se but, with managers who use schedules to beat up developers. I personally think that a manager who beats up a developer with a schedule should be fired on the spot. A development schedule is a tool of trust between a software writer (team) and the manager. It s a measurement tool, that allows the manager to know when his project is facing an obstacle and by virtue of the task list what that obstacle is and how it impacts other tasks and gives clues of how to resolve it. When you beat up the developer, you break the trust on task estimation. Your Engineers "pad" everything and your projects take longer. This is characteristic of the inexperienced or immature manager. You cannot be exactly right on your estimates because they have never been done. So the experienced manager uses the schedule to know where his estimates are wrong and focus more resources on areas where he has underestimated the work (NOT on the Engineers who mis-calculated and unknown task) and get your progam caught up. Thats all. Your Employees come up with the estimates and you manage the results. Management is fairly straightforward if you are a Manager and not a Dictator. Real managers know that trust from your staff is earned, not given, and successful projects come from iteration and repetition of successful patterns of behavior.
Who cares ?
I work in a big (>300'000) service company. I have found out that the quality of the code produced just does not matter. The only thing that matters is that you bill hours to the customer, as long as he agrees to pay them. So work as badly as you can, bill 4 days to implement a check-box on a web-page, and have some PR discuss with the client so that he's not too angry. Nobody cares what the 4 days will be used for, be it actual coding, q/a, never-ending project meetings, administrative stuff or web surfing.
You cannot even try to make good quality because 1. when working on project with many people, you alone doing good work does not mean the result will be good and 2. that would mean less maintenance work afterwards so less money stolen^H^H^H^H^H^Hbilled to the customer.
Mine's the one with the Dilbert sticker stapled on it.
Can't be true..
If a company making as much profit as MS thinks every fourth person must be a manager (Windows 7 development) who am I to argue?
Now, personal experience over 30+ years, yes, managers are needed otherwise there is no time to build systems, to design, to program, to administrate, to .. But one of four?
Logistics, politics, budgets, etc are necessary but boring - so, let's leave that to managers as long as they get us what we need (beer, and so on.. and maybe computers / tools / toys sometimes also) and stay out of how, it seems to give them headache - maybe sometimes asking why because they have to have a good story to tell upwards.
Who pays your salary?
In my experience (20+ years) of small companies, management has never been at nirvana levels of bliss. Poor communication, muddled specifications and moving goal posts abound.
So management is generally rubbish, except that you do occasionally have to remind yourself that a company that only employs developers is unlikely to ever sell anything and then where would you be?
The best developers always have a very clear understanding of where the money for their salaries comes from (customers) and the best managers should be helping the developers to produce the goods that those customers want.
Speaking as a developer - if you don't like your management, then why don't you move on?
Speaking as a manager - if you don't ... oh, I said that already.
It only works if the developers are any good
Many are mediocre to average. In an ideal world the lead developers should coach and use both the stick and the carrot on junior developers, and the manager liaises between management and the developers making sure they have the best possible working environment.
Of course what actually happens is major faults on both sides
Management who will derail the development process just to get a fix that minute or a new feature sooner than is really necessary, and that don't understand why developers should not be distracted from their code.
Lazy developers who don't understand that managing libraries and multiple development environments is a necessary but boring part of the job.
Developers that have the audacity to believe that after being crap at coding with pathetic attention to detail, they would be any good at project management, where attention to detail is the prime requirement.
Click and drool coding such as things that can't be attempted if a third party component doesn't exist, despite the fact it chucks lots of traffic over the network. A complete absence of profiling. Only rudimentary use of error handling. Incomprehension to phrases such as 'design patterns'. Patch management? What's that? Not to mention the expectation their code has unlimited access to everything.
@It only works.....
I have to take exception to the comment that most developers are 'mediocre to average'!!! The vast majority are useless to poor.
To be fair however the poor ones do get weeded out quite quickly to management positions where there inepitude can really shine.
@Who Pays your Salary .....
Yes or maybe it is FOSS.
Why do some many mangers not even fall into the union, never mind the intersection?
What of course really helps these projects are the business analysts. God knows how anybody got anything done with a clear spec from these guys.
Oh yes developers always had to do it themselves, however this is down to their personality nothing to do with project management.
In defence of managers...
We shouldn't overlook the fact that actually it's really, really hard to do it well.
There are so many people with a vested interest; developers, customers, shareholders, wife...
Since they all pretty much have conflicting interests and most managers have managers themselves, it ain't simple.
Some good and insightful comments so far. Additional thoughts:
Regarding manager to employee ratio: At a company I worked for with approx. 150 employees, I and the rest of the engineering department mortals waited outside one of the conference rooms for the management briefing to end. When it did it was amusing and kind of disturbing when one third of the company, all managers, filed out of the room. Oddly enough this was the only company I've come across where the number of employees continually shrank over the years (mostly due to retirement) and this was seen as A Good Thing.
Regarding QA: As usual there is good and bad QA. Good QA of course fends off worthless feature requests et al. However bad or poor QA either simply have no presence (what the hell do they do all day?) or simply bog you down with ensuring that your documents have the correct references and compliance matrices. Ok great, but that QA person is not checking for information accuracy or completeness, nor software functionality or reliability. They're just checking that it really is release 2 and not 2A and that document A has the correct reference number for document B.
Poor QA also seem to hound you to provide the audit trail behind the inclusion of feature X with scant regard for any time constraint or deadline "yeah I put that feature in cos Joe Bloggs the salesman insisted on it at the last minute and that it would clinch the sale, yes the back-of-a-fag-packet he wrote the request on is filed correctly'. Maybe QA should sometimes go after the people actually causing the QA problems rather than those trying to patch it all up?
Ooops this turned into a bit of rant. On a positive note, where I am now allows more free reign over development, more trust and more focus on getting features and stability right with reasonably loose deadlines. This has made me much more inclined to support the sales and QA people and be more flexible to their requests. It's not always perfect but it's better than it has been.
- Product round-up Six of the best gaming keyboard and mouse combos
- China building SUPERSONIC SUBMARINE that travels in a BUBBLE
- Boffins attempt to prove the UNIVERSE IS JUST A HOLOGRAM
- Review Raspberry Pi B+: PHWOAR, get a load of those pins
- Experimental hypersonic SUPERMISSILE destroyed 4 SECONDS after US launched it