Post #28,204
2/13/02 1:32:50 AM
|
No, much simpler than that
They have relatively fixed project and a sane team development cycle.
When the project is developed, it is done. You no longer need everyone working on it. You don't want people to keep working on it indefinitely. You want to wrap the bow, put it in maintainance mode, start getting paid by the client and move your valuable development resources to your next project.
If you can't accept that no single project will get you promoted or permanent tenure, then you are a problem. If you can't accept that you will be working as part of a team, then you are a problem. Company policy is to fire problems.
I think that this policy sounds harsh, but not unacceptably so. As long as you know that those are the ground rules, and as long as the rules are applied with reasonable prior feedback, it is one way to keep difficult situations from growing into major problems. Certainly I have heard of worse. (One policy that I have heard of is to have everyone rank those around them once a year. The bottom 20% at all levels gets fired and everyone else gets their compensation adjusted according to how they did. Real policy, real company. Would you prefer that?)
Cheers, Ben
|
Post #28,211
2/13/02 9:05:20 AM
|
But I have always worked multi-project
you missed my point that I would be working on other projects as well. I would take the "lead" on the project that got dropped, and get it up and running. I would do the same for any other project assigned to me. This would show my value to the company. But I guess being a miracle worker isn't rewarded anymore in the new job market?
My previous employer had me over 112 tasks I was assigned to, when I was let go I had 34 of them left. My supervisor kept coming up with the projects, while there was many of them, a few of them I got recognized for because they saved the company a lot of money and nobody else wanted to do them. My reward, was that I was let go after 4 and a half years so I would not collect a pension, and all of my projects got reassigned to another programmer that also is overworked and they are trying to get rid of. There are programmers there that stick with one project, and don't do anything else, and they get to keep their job. They usually passed the projects they didn't want to do to me because they were hard or next to impossible to implement. So I took them over (I didn't like it, as I did document on here if anyone did bother to read about it, but I did them anyway) and did the best I could on them. yet despite all this hard work, one of the programmers that was a "buddy" to the boss, got the project Leader job, and reassigned his projects to me, and then quit after a few weeks on the job to go back to being a developer. Other developers got let go or forced to quit after big migrations like the CMSOpen migration, the Y2K fix, a SQL Server migration, and most recently the Windows 2000 migration (well the apps part got finsihed, but the techs are still screwing up the release of the W2K workstations).
So I have handled f*cking multiple projects, and I haven't played the role of a "tick". I have moved on to new projects. But I have made some projects the crown jewels in the employer's treasure chest of applications when nobody else wanted to work on them. I also have turned a sow's ear into a silk purse when other developers screwed up their projects and they got handled to me to fix them.
They way it works at my former employer is to hire a group of IT people to work on projects, and then fire them or force them to quit later, then go into a maintenance mode, hire more IT people later for new projects and repeat the cycle to save money on salaries. This gives them a 90% turnaround rate, and they have lost a lot of great talent. But apparently management is filled with a bunch of f*cking morons who only reward those who brownnose, and only the screwups get to keep their job, and the screwup's projects get handled off to those who don't screw up, like me. My former employer has a lot of managers like the one that just left your company.
"Will code Visual BASIC for cash."
|
Post #28,265
2/13/02 2:33:34 PM
|
I think you are still missing the point
(First a minor nit, this is Barry's company, not mine.)
The basic point is that in a team development environment there isn't room for would-be prima donnas. In fact having people try to be that is seriously detrimental to the project and their co-workers.
Now being a prima donna is one way to handle slacking co-workers when you have small projects. But if you are routinely tackling projects that require a division of labour among a half-dozen developers who need to cooperate closely, then most of the time you don't get to be the lead, you don't get to keep the project, and if you try then you are a liability.
You may be used to an environment where a loose cannon can routinely take on multiple projects at a time and complete them. That doesn't scale to more complex projects when you are working on a fixed deadline. My personal further opinion is that where a single developer can keep things humming, I know very few developers who I think would be better at doing that than Barry Roomberg...
Cheers, Ben
|
Post #28,291
2/13/02 5:17:17 PM
|
No, you missed MY point
Projects (from the coder's point of view) have a finite lifespan. People who can can do what I need them to do are far too valuable to waste on a single project. They cost way too much, and can provide far more value, by assigning them to the next project.
The size of the systems I work in require 100% of the coder's attention at first, for several months. There is NO concept of juggling multiple tasks such as these at the same time. The database is 1/2 billion records. And an update can take 2 days or 3 months, depending on the skill of the coder.
And the 2 days coder would NOT be layed off, but the 3 month one should be fired by the 2nd week.
And at least 3 people work as a team, closely. The business analyst, the coder, and the production person have a goal of getting the business rules right, coding, and handing off to production.
And there should be NO lead coder. The business analyst needs to be comfortable the task can be handled by at least 1 other person. If not, it is specced poorly, or requires too much on the coder side, or the hardware is wrong.
We have at least 2 other people in my company who are better coders than me (and I'm f'ing GOOD!), and I hope to bring a couple more along within the next year or 2. I just hired a brilliant 'kid' as a sysadmin, and we did NOT skimp on pay, even though we could since he is young. Any of these people could do my job, given a bit of time to learn the specific project. I just dropped the one I spent the last 6 months on in someone else's lap, to pick up the new one. And this makes ALL of us more valuable.
The core knowledge gained doing these types of projects is very valuable, it is called institutional knowledge. A SINGLE person can never be allowed to hold the company hostage based on that. But when multiple people know this, they can form a strong project team for more money making projects, since assigning people without this experience is a horrible crapshoot, leading to project failures and lawsuits.
From a personal career objective, if you can't be fired you can't be promoted. And in my case promotion does not mean to management slime.
|
Post #28,294
2/13/02 6:37:36 PM
|
I like one of those points
From a personal career objective, if you can't be fired you can't be promoted.
Yep. That one sucks.
We have to fight the terrorists as if there were no rules and preserve our open society as if there were no terrorists. -- [link|http://www.nytimes.com/2001/04/05/opinion/BIO-FRIEDMAN.html|Thomas Friedman]
|
Post #28,317
2/13/02 11:33:37 PM
|
They do it differently
at my previous employer. We worked as a team, but only so that another developer can take over when one is out of the office. As a Programmer / Analyst I had to do the job of several people, and work with an alternate to show him/her what I am doing so they can be a backup. Then work with two or three other developers to integrate my project with theirs so that our programs can share information.
I was the business analyst, the coder, the production person, the workstation tech, the quality analyst, and the debugger and dcoumentor. While the lawfirm could have hired several people to work on a team to get the project done, they decided to hire one person and have him/her do the job of several people. At times this can be stressfull, gut wrentching, and take months to get the project out when I got 34+ other projects to work on and half of them are given high priorities. Was I being a Primadonna? It was not my intention, it was just the way they wanted me to do my job. Believe me, I would have been happier to hand some of those tasks to other people, in fact I had many talks with my boss over that fact.
I code make a code change in 2 minutes or less, but then I would have to thoroughly test the code, document it, go back to coding if the testing showed up a bug, work with the help desk and test users, go back and change the code again, get last minute changes to the code by the managers (Feature Creep), change the code again, test it again, go back to the help desk and test users, fix the workstation issues that the workstation techs can't/won't fix, work to get the finished file out to production, document the changes, check the code into Source Safe, and then start the cycle all over again if a manager changes his/her mind. The code changes might take less than a day, but the BS of the lawfirm can stretch it into months if I have to do the jobs of a lot of other people and the requirements for the program is constantly changing. Then add project juggling of 34+ other projects, and half of them are as important as the one I was currently working on, and you get the idea of how it can take a month or two or three to get done.
I would love to get a job that has me work on a team and just do one part of it.
But as far as taking days or months. Who would you rather build a house for you? A guy who takes 2 days, or a guy who takes three months?
"Will code Visual BASIC for cash."
|
Post #28,354
2/14/02 10:41:54 AM
|
Re: Who would you rather build a house for you?
A guy who takes 2 days, or a guy who takes three months? That depends on whether you want a doghouse or a mansion. I don't think you have an idea how a large project needs to be executed, particularly by people that understand programming development.
Alex
"Of course, you realize this means war." -B. Bunny
|
Post #28,368
2/14/02 11:54:33 AM
|
Bad comparison
Not sure if you were talking about me or Norm though.
I've seen people attempt to update huge data sets in simple SQL updates, watch it fail after 3 days, allocate more rollback space, watch it fail in a week, etc.
The next step is to realize how to do it in PL/SQL, as opposed to SQL, but then you get into other issues, which could allow a single update to go for weeks.
Then you realize how to partition and parallelize your logic, focus your efforts, tune your SQL to not use any tmp space, balance your commits, allocate more memory for the particular transaction, etc, etc, etc, and you are down to 2 days.
While the idiot is still adding rollback segments, and blaming the hardware or the database, and asking to triple the budget because the machine is too "small".
And then, someone says: But that is not an idiot, that is someone merely not trained in that environment. He is a smart, well valued person, who merely needs a little time to get up to speed.
No. Unacceptable. That is why we pay trainees dirt and experienced people gold. And a trainee sucks down an experienced person's time, which means they should be paying us for the priviledge. Go pay Oracle $100,000 and spend 2 years on their equipment. That is why some careers have internships that treat the trainees like slaves, and for good reason.
Your value is based on your value. Not some fuzzy measurement of how you will be in a year, it is how much value you have right now. What do you bring to the table, what projects can you pull off right now, and how is it related to MY industry?!?! Not the industry you came from.
And no, again, knowledge in one product may or may NOT translate to another. I've seen some people here "council" the approach that one database is just like another, and that potential employers should allow for that in their hiring decisions.
This is ONLY true is you take a lowest common denominator approach in your usage of it. Which makes sense for portable coding, but SUCKS for project specific performance issues, which can KILL a project and close the company.
And no again, to if someone knows 8 languages, they will pick up a ninth without a problem. Bullshit. If you know 8 Latin based languages, what the hell makes you think you will pick up Chinese?
Procedural assembler VS procedural BASIC VS COBOL VS Perl VS OO Perl VS C VS C++ VS Scheme VS LISP VS Java VS Java Script VS Bourne Shell VS C Shell VS TCL VS VB 3/4/5/6 VS C # VS every goddamn library in the world VS SQL VS PL/SQL VS Transact SQL VS PostgreSQL SQL VS MySQL VS OLTP VS ODS VS Data warehouse VS JCL VS PL/1 VSMVS VS Unix VS Linux VS VMS VX Solaris VS M$ WinX VS Apple VS AIX VS HPUX VS OS/390 VS (I think you get the point).
You may THINK you really know about 1/10 of the above list, and knowing that 1/10 will dramatically influence how to go about dealing with the other 9/10s. Make a career bet, and always take responsibility for maintaining a forward focus on the next career. It will NOT stay the same in 10 years.
|
Post #28,381
2/14/02 2:13:10 PM
|
Re: Bad comparison.
I'm talking to Norm who seems to think that if you know what you're doing you can do most anything in just a few hours. There are "person-decade" projects. And to pull those off, you need a group discipline.
Alex
"Of course, you realize this means war." -B. Bunny
|
Post #28,422
2/14/02 9:04:48 PM
|
Who me?
Did I say that anyone can do anything in two hours if they knew what they were doing, or did I say that I could make the changes to the code in two hours, and then do the job of everyone else, and come back and make the changes to the code, and do more stuff, and eventually take months? I think I said the later. My former employer has the PHB opinion that everything should take less than a day to code and should be done in a few days, even the most complex of programs and the most advanced of features. If it takes some PHB 15 minutes to draw it in Visio, they think it should take that long to code. But they forget about the debugging, documenation, testing, production, analysis, and workstation issues cycles. I could make the changes in a day, but take weeks to complete the other stuff, and work with the helpdesk and managers to "tweak" the program to their everchanging specifications.
If it was normal stuff, and I worked in a true team environment with other people filling the roles that my former employer had me do, and I only did the coding part. I could spend a few hours or a few days to code it, and then hand it off to someone else to test it, fix the workstation issues, release it into production, etc. If I was given a blueprint for the program or told to do the analysis myself instead of an everchanging project spec that gets updated at the last minute just before I leave for the end of the day so I'll have to recode and stay extra hours, and nobody knows the whole picture but keeps changing it anyway, then it takes longer.
But if I had more projects to work on, like 34+, it would take longer because I'd have to juggle those other projects. Management still does not understand why we take longer when they bury us in projects and insane demands. Like the CDW commercial "What is the matter Norman? We are only asking for the impossible in too short an amount of time."
"Will code Visual BASIC for cash."
|
Post #28,411
2/14/02 6:10:53 PM
|
And if no one has experience with the technology?
That's when you pay someone for what they can learn, right now.
For example, find me someone who is experienced writing code for the Marposs E96 measuring system. Well, the total in the world right now is under five people. So I'm learning right now, and I am using the scripting approach (Python) to customization, vice tables or flat files, because for the degree of customization our customers ask for, tables do not provide enough flexibility.
Since my company also does a lot of custom work, with customers that like to specify equipment ('must use PLC Direct DL205 PLCs', 'must use General Electric 300 series PLCs', 'must use Galil controller', etc), we have to be able to learn new stuff in a hurry.
Of course, we could try finding experts on the equipment, and then either contracting the work out or hiring then firing when the work is done. This approach has a lot more problems, such as finding people with both equipement knowledge and domain knowledge, and a real loss of domain-specific knowledge for the company.
I'm not trying to be critical, just pointing out that different situations require different approaches -- and different skill should be more highly valued; I don't doubt that your approach works very well for your business.
Tony
|
Post #28,413
2/14/02 6:46:14 PM
|
Then you don't pitch yourself as experts
We sell "solutions", not technology.
We are primarily a print company, ie: junk mail. Also, statement printing. BIG PRINTERS. LOTS OF THEM. Football fields worth.
That is 90% of the business.
Then we have the merge/purge / data warehousing side, the "boutique". Print customers want us to handle their dirty data, which then feeds more print jobs.
So we choose the appropriate technology to do the job, not the other way around.
If THEY chose, it would be on a time and materials basis, with no end point in sight.
If I was in your position, I would attempt to price the 1st project in new technology so I could afford to hire the expert, and do joint work to enable knowledge transfer. But you might actually price it much lower, to get the business in a new area, which then adds to your corp experience, which can then bid on a wider variety of projects.
|
Post #28,416
2/14/02 8:34:14 PM
|
But there may not be an 'expert'
depending on what we're doing. There is nothing equivalent to our standard machines (for hard drive head stack measurements), so all the experts are in-house people who have learned on the job. On the custom machines, it varies; some are more unique than others. It's quite possible that NONE of the companies bidding are experts at building the customer wants built.
It's also harder to judge ahead of time what will be the best approach for a given set of requirements, especially since the customer requirements sometimes changer AFTER the machine has been built.
However, there are several tactics that we do use to reduce risk. Basically, we're system integrators, putting together complete solutions (standard hardware + software components, tied together by our custom hardware and software into a complete machine).
So our vendors are a big source of help. Factory automation vendors charge a hefty premium over the cost of materials; the good ones, like Adept Robotics, provide excellent support. If we can buy a standard product to do the job, we'll do that instead of building it ourselves. And if there's a subsystem that is out of our expertise, we'll subcontract out that subsystem.
Even though we don't like it when vendors spec equipment, they can have good reasons for doing so, because they have to live with the machine, maintaining it and sometimes upgrading it (for custom machines, the cost includes the control software source). So, for example, if all the other machines in their factory use Allen-Bradley, they'll probably spec Allen-Bradley, even though A-B is several times more expensive than Automation Direct, because it saves on spare parts and their technicians already know the Allen-Bradley controllers. Or there can be regulatory reasons; A-B is qualified for use in medical systems (FDA approved), while I don't believe Automation Direct is. Of course, if we get a sales lead from a manufacturer (e.g. Adept), we have to use their equipment.
As far as being an experts, well, that does depend on the area. We are experts in metrology (because of our parent company). I'd say we're experts in certain areas of automation. If we get into an area that was close enough so we're comfortable we can do it in-house, we'll use the a combination of our learning + vendors. If it's beyond what we're comfortable with, we'll either subcontract out a subsection, hire a contractor, or hire a new employee.
Basically, our business is different from yours. In most cases, it makes more sense for us (existing engineers) to learn the new areas, rather than hiring experts. So I place a higher premium on ability to learn AND experience (and wide experience helps, too, especially during project definition).
I do agree with most of what you say, especially on topics such as knowledge transfer. It's extremely important spread knowledge around in-house so that no one is indispensable.
Tony
|
Post #28,470
2/15/02 9:09:04 AM
|
I would love a time and materials no end in site gig
Those can be the best kind as long as the customer is happy with the work. thanx, bill
Mike Doogan "Then there's figure skating and ice dancing and snowboarding. The winners are all chosen by judges. That's not sports. That's politics. And curling? If curling is a sport, pork rinds are a health food."
|
Post #28,456
2/15/02 6:16:18 AM
|
Seen something similar
Just recently saw an application that used complex SQL statements (sorta depending on the database optimizer to optimize them) where the optimizer turned brain-dead.
Sometimes, the human brain really is smarter than these "intelligent" algorithms they put into databases nowdays. The particular statements in question would *probably* be executed much faster by splitting the statement (a multi-table select) into separate statements, or by using (alas proprietory) database directives to tell the optimizer what to do.
Where each demon is slain, more hate is raised, yet hate unchecked also multiplies. - L. E. Modesitt, from his Recluse series
|
Post #28,334
2/14/02 7:54:58 AM
|
And if you work in-house support?
Currently, I'm not working on any particular project (well, one, but that's on hold for financial considerations, which is another problem entirely). I'm working on supporting "infrastructure" (nice buzzword, eh?) and the occasional help center problems. Did I ever say I hated m4? We've got one of the weirdest m4-driven report systems (don't ask) I've ever seen. If you don't know what m4 is, you don't really want to know. Once really addicted, users pursue writing of sophisticated m4 applications even to solve simple problems, devoting more time debugging their m4 scripts than doing real work. Beware that m4 may be dangerous for the health of compulsive programmers. (from [link|http://www.cslab.vt.edu/manuals/m4/m4_1.html#SEC1|Introduction to m4]). Some of the stuff I debug has to do with an addictive m4-coder. Damn the bastard.
Most of the work of government does not need to be done. - Attributed to Ronald Reagan, under whose administration the government expanded, of course.
|