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.
|
