• Low cost to entry
• Any Joe Idiot with a stupid idea can set up a web site.
• Then, Joe Idiot can claim to be the leading web site selling blue widgets made in Antarctica.
• Then, legends of starry eyed techies take pay cuts and promise to work 80 hrs a week to join the pre IPO web company because Wall Street will buy anything.
• Rapid change in direction or "Corporate Mission"
• Since the "community site" didn't work last week, we think that we should be a portal this week.
• Well, the portal didn't work, we're now a "B2C" site, then "B2B", then "ASP", then "ASP B2B", then....
• No communication between Management, Marketing, Sales, and Systems Administration
• Since Management forgot to tell Marketing that the "B2B" idea is dead while they are writing their next business plan for the "ASP", the marketers are still selling space on the "B2C" site, the developers are still writing code for the for the "portal" site, and system administrator is still setting up mail accounts for the "community site".
• We can't afford to waste time on meetings!
• We'll get a project manager (or product manager, depending on what we are doing that week) soon.
• Ridiculous expectations
• CEO and upper management expects 100% system uptime forever without any maintenance windows (and they only have one primary system, no secondaries or backups)
• CTO wants "Bank like security", but we can't spend any money on a firewall.
• CTO wants "Bank like security", but the developers can work from home and must have complete access to the LAN from anywhere in the world (and we can't afford a VPN solution).
• CTO wants "Bank like security", but he says that the developers can't be bothered with packaging their code for releases so the production systems are simply set up to allow password less root logins so that the developers can just rsync their code up to production.  Humm, how did those nasty pictures get onto the production web site????
• Thinking that we don't need an Oracle DBA because one of the developers has used MS access in the past and can do it.  Humm, what's a SGA again?
• Thinking that one used Dell server with 1 300Mhz CPU and 128M of RAM can handle all development tasks such as running 3 Oracle databases, 15 development web servers, 15 instances of the java servlet engine, bug tracking system, mail server, and Internet router with ipchains packet filters.  Question from the CTO: "Why is the system so slow?"
• Thinking that the one used Dell development server should also be used to preview customer's web sites so it should be open to the Internet.  Humm, did a hacker get in last night thru that upload servlet that was being developed?
• Thinking that the SA should support and have expert knowledge of all mail clients ever created (Netscape, Explorer, Outlook, Eudora, pine, elm, etc.) on any platform (Linux, Solaris, Win 3.1, Win95, Win98, WinNT, Win2000, MacOS, BeOS, etc.).
• Thinking that SPAM is a really good and cheap marketing campaign.
• Thinking that your major (and very large) competitor won't sue you when you collect user's e-mail addresses from their web site and SPAM their customers.  (The competitor did, they won).
• Thinking that the FTC won't sue you when you send a major competitor's customers a misleading SPAM. (The FTC did, they won).
• Thinking that having 300 domain names and setting up e-mail accounts in all of them for all employees is a good idea and should not be a problem for the SA.  And then wanting aliases for every permutation of each employee's name for each mail account.  And then wondering why no one knows where their e-mail is going....
• Thinking that all e-mail should be delivered in 5 seconds even when the WAN connection (a DSL line) is down or the other side's e-mail server is down.
• Thinking that the fact that someone else's e-mail server is down is my (the SA's) problem and I should fix it.
• Thinking that sending all corporate announcements in MS DOC format is a good idea even when all of the developers and the SA are using UNIX or Linux.
• Bad QA and testing
• Not having a complete testing environment.
• Testing on the production systems.
• Thinking that correcting bugs and releasing to production 5 times a day is not a problem.
• Note to upper management: If you release twice a day, you don't have QA.
• Bad system backups
• Using a CD-ROM burner to backup a 36G development system.
• Once management finally understands that it takes 60 CDROMs to do a full system backup they spring for a used 15G DLT tape drive ($150.00) but no backup software.  If you exclude all of the Oracle databases you can almost get a full system backup.   However, management still doesn't understand why you would want to do a full system backup....  Hope the machine never crashes a hard disk....
• When a restore has to be performed, management is upset that it takes 4 hours to locate the correct backup tape and restore the directory that was deleted since the whole process is manual.

Return to Unixhub's home page