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
|
