|
The IT support at my working place is very slow. If your hard drive crashed they eed >3 days to exchnage it and install the image!! of the opperation system. And then now development tools are installed. If I install the system by my self I can do it in a half day with all software. That's very bad support.
Ciao
|
|
|
|
|
I wish you could have put like 3 checks next to 'Better Planning'.
|
|
|
|
|
I would have to agree with you there -- great planning and good process, make up for bad hardware, bad IT, bad everthing else.
What use is good hardware, if your planning is poor. The best SW Engineer can't make up for bad planning either.
I thought that was the no-brainer. No matter how good your planning is, there's room to make it better.
If your planning is so good, how come you haven't made your millions....
-p
|
|
|
|
|
I typically face two problems all the time:
1. Due to competitive budgets I, and many others I know in my field, lack all the required tools. Tight schedules expecting miracles also typically do not provide the funding to purchase the tools (and the required number of seats) to have hope for achieving those miracles.
2. Lack of communication. Productivity of multiple organizations, the quality of the end product, and the schedule all suffer due to lack of communication & coordination between teams and organizations. Of course, all this adds up to make customers unhappy and leads to a bad rep. You can not get people where I work to communicate. They will not use what tools they *do* have for communication to ensure that everyone has all the information that they need. Design and code continually has to be reworked because one team does one thing and other does something else and they don't work when you integrate the pieces. When you try to make things better/easier, it achieves nothing. Unfortunately, this also leads to the talk of achieving a CMM Level 3 or above laughable in most situations that I've encountered because few projects allow time and money to do the tremendous amount of extra work necessary to achieve the CMM rating. Sometimes I just want to smack some people around!
WillCodeForMoney
|
|
|
|
|
When working on a big project the importance of good tools is more important comparing to small projects. It is important that everyone stores code and docs in one place, that anyone can easily post new ideas, etc. Things like Knowledge Management become quite important.
Better planning, design, QA, is another aspect.
But the most important is to have a good looking, always smiling assistant!
Igor Proskuriakov
|
|
|
|
|
I agree in the use of the collaboration tools -- for managing documents as well as code. Tools to support collaboration on revs and approvals to the tools, etc. However, as I stated in my other posting in this discussion, no one wants to use them here! I hope that I will soon be in a position to start influencing teams to make use of the tools available and do their jobs more efficiently.
WillCodeForMoney
|
|
|
|
|
It used to really wind me up when a small Engineering team would put together a bid for a contract and the Marketing rep nominally responsible got the commission.
Not much of an incentive for everybody "downstairs" to do their bit to put together a winning bid, is it?
At least where I am now we get an annual profit related bonus. Kind of takes the sting out. A little.
Andy Metcalfe - Sonardyne International Ltd (andy.metcalfe@lineone.net) http://www.resorg.co.uk
"I'm just another 'S' bend in the internet. A ton of stuff goes through my system, and some of the hairer, stickier and lumpier stuff sticks."
- Chris Maunder (I just couldn't let that one past )
|
|
|
|
|
Well our sales rep gets his comission on signing of the project and then on successful completion of the project us developers get our "comission". So it works out pretty well.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"We would accomplish many more things if we did not think of them as impossible."
- Chretien Malesherbes
|
|
|
|
|
Bonus?! What's that?!
WillCodeForMoney
|
|
|
|
|
is secretary-women included into the same column as qa?
can be coffee and (soft?) drinks in more-help section too?
t!
|
|
|
|
|
Personally I think that the better the equipment, and the more numerous the productivity enhancement devices (such as cool cell phones, PDAs, flat scree LCDs, super thin laptops etc) the more productive I would be.
Honestly.
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
MORE TOYS!!!
I right now am looking at spending another $1100 on toys to help me be more productive.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Perhaps $11,000 would be better try
|
|
|
|
|
Yup
wish I had a P-4 with 1 GB ram (((
I am on a p-III 600MHz with a pitiable 128 MB ram
waaaaaaaaaaaaaaaaaaah
Nish
|
|
|
|
|
I wish I hade a coffemaker that could brew faster than my old one!
/Jarek
"Imagination is more important than knowledge, for knowledge is limited while imagination embraces the entire world."
-Albert Einstein
|
|
|
|
|
Hi,
Software development texts such as, Mythical Man Month, Peopleware and Rapid Development, present reports that state environemt has a huge effect on productivity. Something like twice as much work is done in an office with a door you can close compared with a cubicle or open plan.
They say it stems for the fact that, on average, managers needs to maintain a single throught for 6 minutes at a time whereas a developer thinks for 2 hours at a time.
Interesting stats, pity management does not understand the logic.
See ya.
|
|
|
|
|
managers needs to maintain a single thought for 6 minutes at a time whereas a developer thinks for 2 hours at a time.
I never thought about it that way. Wow.
It would be interesting to see one of those experiments where they measure the activity in a persons brain and compare a manager (or other non-programmer-subtype) with a programmer. I wonder if there is a special bit of the brain that grows larger the more we program (and causes a corresponding part of the brain - say, the social development lobe - to shrink...)
cheers,
Chris Maunder (CodeProject)
|
|
|
|
|
Well, being more in the management role myself I would like to step in and defend most managers.
This whole 6 minute vs 2 hour thing is perfectly valid, but for a reason. It is not a bad thing at all, on either side.
Developers need to focus and concentrate on the task at hand. Most problems are not solvable in 6 minutes, 30 minutes or an hour. A good 2 hours or more of solid uninterrupted work must be spent to achieve good results.
You hire developers for their ability to solve programatic problems.
A manager who focuses on one thing for 2 hours is going to loose the plot, loose control and miss important issues which need to be resolved. 6 minutes is spent handling a testy client, firing off a project report email, answering to the boss or a myriad of other small, seemingly easy yet decidedly non-trivial things. If developers had to handle all the minutea of a project no problems would be solved and a half baked system would emerge.
You hire managers to keep the crap and every day problems away from developers.
So I say: Be thankful your manager keeps the millions of irritating questions and problems away from you developers. I am just as thankful for my developers who can focus and get a job done, knowing they won't be interrupted every 6 minutes.
and if anyone ever tells me that managers are of no use and don't work hard enough then come spend a day by my office and have your head corrected...
that was my two cents
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"We would accomplish many more things if we did not think of them as impossible."
- Chretien Malesherbes
|
|
|
|
|
I have to agree with Paul here. I am the President and primary programmer for my company. So I see both sides.
Comparing the amount of time is interesting, but about as valid as comparing the number of lines required to write a "Hello World" program in different language.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Tim and Paul have highlighted that I failed to make my point.
That being, if a developer is twice as productive in an office then it is more cost effective to have the developer in the office and the Manager in the cubicle. This has other advantages such as halfing the number of developers required to develop the same product or doubling the speed it is developed. It also dramatically reduces bug count.
Unfortunatly, social stigmas prevent grunts (code cutters) having offices when managers, sales and marketing have cubicles. Many very sucessfull companies have overcome this by setting up seperate development offices to save money. 100 developers in their own offices cost less than 200 developers working in a busy hallway between the sales department and the bathroom.
Everyone works hard. The quesiton is, how to make that work more productive?
Australia is a nice place to work. But New Zealand is the best place to live.
|
|
|
|
|
Actually I dont really agree that it is more productive to have the developer in an office.
The team I am currently working in is situated in a large room and we are all in half cubicals around the perimeter of the room. I can just turn my head, or shift my chair a few inches and see or talk to any of the other team members.
A few years ago, I would have said that this is the worst possible working environment, but now I believe that not to be the case.
If I have a question, or need to work on a bit of code that one of the other guys has checked out, all I have to do is ask the question, or request that the file be checked in. I dont have to get up from my desk, walk to another office and do it. We find that the distraction is actually less than if we have to physically move away from the desk.
Communication is much better in an open environment, everyone feels free to throw their two cents in when a couple of the developers are talking code. This has produced benefits on a number of occasions when a better solution was suggested by a third developer.
I guess the proof is in the pudding. We are coming to the end of the current project. Apart from schedule problems that were completely outside our control, as well as the team members being pulled off for other projects, in the midst of scope changes, and some largish reworkings that have been required, our project is very close to the projected budget with just a few months to go (out of two and a half years of development).
The next project that I am assigned to, I am definitly going to suggest the open plan approach. Through my entire career it has been the most effective way of teamwork that I have encountered.
regards
|
|
|
|
|
Try working in a busy hallway between the sales department and the bathroom
"I never met anyone I didn't like" Will Rogers.
|
|
|
|
|
Well I have just experienced a bit of "environmental comparison" myself.
I travelled to London and had to use someone elses computer along with being in a noisy and cluttered office. While luckily the point of my trip was not to do much coding I had to dig into some projects now and then. I found it very difficult to focus and concentrate on the task at hand. Much of the time I struggled with getting to grips with a different computer (UK keyboard as opposed to the American one, programmes in different menus, different partitions and a different server structure).
So environment does pose a big factor in productivity.
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"We would accomplish many more things if we did not think of them as impossible."
- Chretien Malesherbes
"Give me something better than Windows and I will use it, till then leave me be. Give me soemthing better than Science and I will believe it, till then leave me be." err, me
|
|
|
|
|
...for ( ) managers!
|
|
|
|
|
Better training in what regard? Better planning, project management and strategic training or better technological training?
Though I do know of a training course for managers which I heartly recommend: How to serve your developers proper coffee, 101
regards,
Paul Watson
Bluegrass
Cape Town, South Africa
"We would accomplish many more things if we did not think of them as impossible."
- Chretien Malesherbes
|
|
|
|