A couple months ago I attended a breakfast put on by uita (uita.org). There was a forum of business owners who now run local IT companies but had previously run companies in New York, Chicago, and Silicon Valley. Here are some quick things they noted about Utah compared to these other places:
-There are no senior mentors. There are no 20 year veterans of big business IT or opportunities to learn from such people.
-IT company owners do not stick it out. If they strike it big, they go to a ranch and retire, and if things go bad they don't stick it out.
-The lack of senior IT mentors means that there is a lack of people who have the experience of passing through the "valley of death of business".
-For people who are not members of the predominant religion, it is a difficult place to transfer to. Most people in Utah turn to their families outside of work and neglect social activities that would interest people in other states (the arts, etc.).
-In other cities in the U.S., employees jump ship quickly. They work much longer hours and are concerned primarily with themselves, unlike it Utah.
-People are very loyal to their companies in Utah.
-The ethics of most people in Utah are very high.
-The supply of good sales people is depleted compared to 5 years ago.
-UTFC funds a lot of IT companies.
Saturday, December 31, 2005
Tuesday, August 23, 2005
Ruby on Rails
Ruby on Rails is the buzz right now in the java community. At our company where we are predominantly a java shop, we have recently done a significant project in Ruby on Rails (ROR).
It is perhaps premature to pass judgement since we haven't developed in it for very long, but it is too tempting to resist predicting the future.
Coming from a background of programming in many different web programming languages on large projects, I have a different perspective from many people who have become entrenched in particular languages. For better or for worse, I see things differently than many people.
In this case I see ROR as being a major player in the future but still seriously flawed.
Let me give some background before elaborating on that thought. Today there are many programming environments within which a person can build effective websites. From a management perspective, it really doesn't matter which platform you build on, as long as it works.
From the trenches of programming, however, there are markedly different people who make up the group known as programmers. Many people who go to solid 4 year schools that teach theory end up making up a certain group of thinkers. On the other side of a polar extreme is a group of home grown computer hobbyists and programmers--and dare I say it entrepreneurs. Like anything in life, the situation isn't black or white, but the dichotomy of these two groups and the philosophies they bring to work each day has really driven a lot of the creations, the languages, frameworks, and platforms, that are making a splash and going places in the technology community today.
Ruby on Rails has a strong appeal to java developers. For the most part, the people that drive java architectures at any company tend to be school educated people who are well based in theories about Object-Oriented advantages and Model View Controller architectures. This group cares a lot about writing "good" software and following "good" methodologies. Within a company of java developers there are architects that are considered very bright and there are guys who learned how to do java witout much theoretical schooling (or they got the schooling and never cared) and they often go with the flow and learn repetitive tasks.
On the street I see the hobbyist programmers making up a lot of the millionaires and they really do things differently. For them, they care about business models and not software models. They tend to gravitate toward simple and straight forward approaches to problems, and are drawn to the easiest programming environments around.
When I see ROR, I see something that appeals to the educated and those that follow the latest theories on software development, but to the entrepreneur it is filled with a lot of baggage that does not get the job done clearly and effectively.
One of the main differences between java or ruby on rails and other scripting environments is how a developer perceives a website. Java and ROR tend to make you think of a website in terms of an inter-related "project", like a car engine for instance that has lots of parts and touches electrical system and air conditioning and the transmission. Many scripting languages, such as Perl or PHP tend to approach things in much more discrete units, maybe like a table full of cups of soda. Rather than being tightly related, they are more loosely related and you can toss and replace an individual unit cleanly without affecting the rest of the system (which is a place to grab a drink).
A hobbyist developer is someone who will throw up a couple web pages and organize them into folders if it occurs to them. They might decide to do something neat someday, like return content from google or interact with a credit card gateway. By perceiving of the problem as a one or two page problem, and by using a scripting language that allows them to do these phenomenal tasks in a couple lines of somewhat readable code, they are able to learn programming quickly and keep their focus on business models.
From the perspective of a hobbyist who has a web page, trying to learn about object-oriented programming and inter-related software systems and patterns and frameworks of implementation are too much of a leap for them. Although Ruby on Rails writes a lot of code for you, it takes you out of a paradigm that is simple and based around the idea of a simple web page.
Looking toward the future, I see entrepreneurs continuing to use tools like PHP, while the educated groups out of colleges will lean toward object-oriented languages and significant theoretical underpinnings of frameworks and patterns. Because of this trend the better educated people will write the best software from a technical standpoint, and the entrepreneurs will continue to lay golden eggs with sites made of easy to learn scripting code.
After all is said and done, this situation really parallels the sitauation we are in today. I guess the more things change, the more they stay the same.
It is perhaps premature to pass judgement since we haven't developed in it for very long, but it is too tempting to resist predicting the future.
Coming from a background of programming in many different web programming languages on large projects, I have a different perspective from many people who have become entrenched in particular languages. For better or for worse, I see things differently than many people.
In this case I see ROR as being a major player in the future but still seriously flawed.
Let me give some background before elaborating on that thought. Today there are many programming environments within which a person can build effective websites. From a management perspective, it really doesn't matter which platform you build on, as long as it works.
From the trenches of programming, however, there are markedly different people who make up the group known as programmers. Many people who go to solid 4 year schools that teach theory end up making up a certain group of thinkers. On the other side of a polar extreme is a group of home grown computer hobbyists and programmers--and dare I say it entrepreneurs. Like anything in life, the situation isn't black or white, but the dichotomy of these two groups and the philosophies they bring to work each day has really driven a lot of the creations, the languages, frameworks, and platforms, that are making a splash and going places in the technology community today.
Ruby on Rails has a strong appeal to java developers. For the most part, the people that drive java architectures at any company tend to be school educated people who are well based in theories about Object-Oriented advantages and Model View Controller architectures. This group cares a lot about writing "good" software and following "good" methodologies. Within a company of java developers there are architects that are considered very bright and there are guys who learned how to do java witout much theoretical schooling (or they got the schooling and never cared) and they often go with the flow and learn repetitive tasks.
On the street I see the hobbyist programmers making up a lot of the millionaires and they really do things differently. For them, they care about business models and not software models. They tend to gravitate toward simple and straight forward approaches to problems, and are drawn to the easiest programming environments around.
When I see ROR, I see something that appeals to the educated and those that follow the latest theories on software development, but to the entrepreneur it is filled with a lot of baggage that does not get the job done clearly and effectively.
One of the main differences between java or ruby on rails and other scripting environments is how a developer perceives a website. Java and ROR tend to make you think of a website in terms of an inter-related "project", like a car engine for instance that has lots of parts and touches electrical system and air conditioning and the transmission. Many scripting languages, such as Perl or PHP tend to approach things in much more discrete units, maybe like a table full of cups of soda. Rather than being tightly related, they are more loosely related and you can toss and replace an individual unit cleanly without affecting the rest of the system (which is a place to grab a drink).
A hobbyist developer is someone who will throw up a couple web pages and organize them into folders if it occurs to them. They might decide to do something neat someday, like return content from google or interact with a credit card gateway. By perceiving of the problem as a one or two page problem, and by using a scripting language that allows them to do these phenomenal tasks in a couple lines of somewhat readable code, they are able to learn programming quickly and keep their focus on business models.
From the perspective of a hobbyist who has a web page, trying to learn about object-oriented programming and inter-related software systems and patterns and frameworks of implementation are too much of a leap for them. Although Ruby on Rails writes a lot of code for you, it takes you out of a paradigm that is simple and based around the idea of a simple web page.
Looking toward the future, I see entrepreneurs continuing to use tools like PHP, while the educated groups out of colleges will lean toward object-oriented languages and significant theoretical underpinnings of frameworks and patterns. Because of this trend the better educated people will write the best software from a technical standpoint, and the entrepreneurs will continue to lay golden eggs with sites made of easy to learn scripting code.
After all is said and done, this situation really parallels the sitauation we are in today. I guess the more things change, the more they stay the same.
Wednesday, July 13, 2005
Buy or Lease Servers?
Every week I get bombarded with emails and advertisements for server hardware and software solutions. Obviously there are a lot of people out there who like to bring things in house, but I am here to tell you today that owning your own hardware is like buying your own cow to get your daily milk. Or do you remember in that cartoon the Incredibles that the seamstress says "not capes" and the hero says "but..." and the seamstress gives the examples. Let me give you a few.
A year ago I walked into a situation at a company that had recently been sold in which the data of 20,000 customers was sitting on two servers up in a data center. If those servers were to fail and the data were lost, the company would probably cease to exist. Most of the former IT employees no longer worked at the company as a result of the uncertainty that existed before the sale of the company, so there weren't many resources around to address the issue of how to manage the servers.
I started asking question such as "Where is the data backed up?" and "What is the recovery plan if something goes down on the servers?". It turned out that the configuration of a new server to support the customers was not a copy/paste recovery process. It was days of configuration to get things back up to running again on a new box if a processor or motherboard died (and the servers were already many years old and running 24 hours a day under tremendous loads).
As you look at this problem, it could happen anywhere. All you have to do is put a box in a data center and your problems begin. What do you do? Do you buy redundant hardware at $3-5000 per server? That is a lot of money to just have sitting around turned off! Do you use tape drives and arrays of disks? Who are you supposed to call to put humpty together again if the guy who installed the proprietary tape drive system is no longer around and you have a component failure in the server and need to get the data out? What if you have everything on your array of disks but you can't get the sucker installed in the latest box because the first time you installed it was a couple operating systems ago? What if one disk fails in your array and you they haven't made that drive for 4 years and you can't buy one? What if the ram fails and it takes you 48 hours to ship in the proprietary type that works with your big-name server?
Another company I know of loses an incredible amount of money each year because their programmers are busy fiddling with the firewalls and network that protects a couple really boring/low traffic servers. The wasted payroll of this effort is in the tens of thousands of dollars each year, and the lost opportunity cost that occurs as projects don't get completed and customers go to other vendors reaches into the millions.
At the end of the day, it is very expensive to own hardware and hire the resources to mantain those servers, especially considering that the maintenance should only happen once a year when something fails.
I think it is important to qualify this perspective. Some companies are like grocery stores in that they are huge and need a lot of "milk" or servers in this case, and it makes sense that they have people and extra hardware to handle these things. Interestingly, however, most businesses are nowhere near this big, but far too many of them pay big money and put themselves in bad situations when disasters happen, and it doesn't need to be that way.
In our case, for about $200 a month, we can pay for a leased server that is top of the line in a data center that is top notch. By going with one of the big boys, we are guaranteed hardware replacement when anything goes down, and guaranteed there are lots of spare parts for our server for years to come. The cost savings and reliability of such a solution or amazing. We have to watch our backups and know how to get back up again if there were any problems, but for the most part we are freed up to do what is most important, and that is make the company lots of money.
A year ago I walked into a situation at a company that had recently been sold in which the data of 20,000 customers was sitting on two servers up in a data center. If those servers were to fail and the data were lost, the company would probably cease to exist. Most of the former IT employees no longer worked at the company as a result of the uncertainty that existed before the sale of the company, so there weren't many resources around to address the issue of how to manage the servers.
I started asking question such as "Where is the data backed up?" and "What is the recovery plan if something goes down on the servers?". It turned out that the configuration of a new server to support the customers was not a copy/paste recovery process. It was days of configuration to get things back up to running again on a new box if a processor or motherboard died (and the servers were already many years old and running 24 hours a day under tremendous loads).
As you look at this problem, it could happen anywhere. All you have to do is put a box in a data center and your problems begin. What do you do? Do you buy redundant hardware at $3-5000 per server? That is a lot of money to just have sitting around turned off! Do you use tape drives and arrays of disks? Who are you supposed to call to put humpty together again if the guy who installed the proprietary tape drive system is no longer around and you have a component failure in the server and need to get the data out? What if you have everything on your array of disks but you can't get the sucker installed in the latest box because the first time you installed it was a couple operating systems ago? What if one disk fails in your array and you they haven't made that drive for 4 years and you can't buy one? What if the ram fails and it takes you 48 hours to ship in the proprietary type that works with your big-name server?
Another company I know of loses an incredible amount of money each year because their programmers are busy fiddling with the firewalls and network that protects a couple really boring/low traffic servers. The wasted payroll of this effort is in the tens of thousands of dollars each year, and the lost opportunity cost that occurs as projects don't get completed and customers go to other vendors reaches into the millions.
At the end of the day, it is very expensive to own hardware and hire the resources to mantain those servers, especially considering that the maintenance should only happen once a year when something fails.
I think it is important to qualify this perspective. Some companies are like grocery stores in that they are huge and need a lot of "milk" or servers in this case, and it makes sense that they have people and extra hardware to handle these things. Interestingly, however, most businesses are nowhere near this big, but far too many of them pay big money and put themselves in bad situations when disasters happen, and it doesn't need to be that way.
In our case, for about $200 a month, we can pay for a leased server that is top of the line in a data center that is top notch. By going with one of the big boys, we are guaranteed hardware replacement when anything goes down, and guaranteed there are lots of spare parts for our server for years to come. The cost savings and reliability of such a solution or amazing. We have to watch our backups and know how to get back up again if there were any problems, but for the most part we are freed up to do what is most important, and that is make the company lots of money.
Tuesday, July 12, 2005
Java vs PHP and other scripting languages
It is amazing to me that after having created so many large applications in so many languages for so many companies, that after 8 years I still find myself in heated conversations with developers about which language to use to create the next web application. In the back of my mind, I have some pretty solid answers to most problems, but when I talk with very educated people who are in complete disagreement with me, it is reasonable that I second guess myself.
Some recent events brought a lot of clarity to this argument, however. As my team and I prepared to develop a major application I decided it would be fun to revisit a test I did about 5 years ago, and compare Resin (a Java application server known to be one of the fastest on the market), to PHP. Five years ago I found that by simulating 50 simultaneous requests to applications with a Mysql back end database, that the server came under almost no load when using PHP, while the Java stuff not only used 50% of CPU and RAM, but also ran considerably slower (2-3 times).
And so a few weeks ago I grabbed an old box, probably around a 1.5 Gig Pentium box with maybe 500 Megs of Ram, and installed the latest RedHat Fedora Linux. I figured that since our data center boxes are much more powerful than this hardware, it would be a good test. I put a lot of thought into how I would benchmark the applications in Java and PHP under various scenarios, and I ran the first test under PHP. I created a 500 character block of text and inserted it into an empty database 1 million times. This took about 2 1/2 minutes and the server did show that it was feeling the load, although I can't remember exactly what the load was because I planned to do the test again and then document the results. Something to keep in mind is that I was running the desktop environment on the box rather than just using the command line and it seems that the desktop GUI takes a ton of processing power away from the computer on such old hardware, so there were a number of factors contributing to a less than optimal running environment for the PHP application--but it was still really fast.
I then asked our top Java engineer, who has written significant J2EE applications for years, to set up the java environment to do the same test as I did in PHP on that server. He said it would be just a few minutes. Well, 4-5 hours later he gave up on setting up the environment because there were some libraries missing when he tried installing the new Java 5.
Now this was not the intention of the test, to highlight that one of the differences between Java or other "Enterprise" develpment environments and scripting languages is the speed of getting set up to do work. It is interesting to note, however, that I used PHP out of the box and had it running a heavy test within a very short time.
How fast you get you environment up and running is not really central to the discussion of when and where to use Java or a scripting language, so let me return to that discussion.
Some of the many things that cloud the issue of whether to use a scripting language or a language like Java is the discussion of frameworks, design patterns, and object relational database mapping. These topics are a combination of both theory and best practices and tend to be driven largely by the academic realm of universities and classrooms. But after years of indoctrination both in the classroom and in the real world about the many frameworks and patterns and object-oriented programming techniques, let me compare and contrast applications written in both scripting languages and enterprise platforms in production scenarios.
One of the largest applications I ever built in a scripting language consisted of 120 dynamic pages. It was an intranet application used for many different departments and every page was needed (no redundancy). The processing for every page was very simple, similar to the actual needs of most web applications I have ever worked on. For every form, there was a corresponding block of processing code which would cliean up the data a bit and update some information in the database, and do it all in just a few lines of readable code.
One of the largest projects I have worked on in the java realm was a 300+ page online banking application. It had all the buzzwords, it used model/view/controller and it was multi-tiered with presentation, business, and database layers. Obviously it was a bit complicated to work on but everyone at the company felt that in a mere 6 months an average java developer could get around the software effectively enough to do things without having to ask others how anymore. Although I've expressed a little sarcasm, I'll be honest in saying that the software was actually very well architected.
So what does this all mean? Well, recently I read an article about the 10th anniversay of java and it featured an interview with James Gosling, the creator of Java. He was asked about his perception of scripting languages. He said something to the effect that java for web applications (J2EE) and scripting languages are different animals. He said in essence that scripting languages are great for protyping and getting an application out the door with an emphasis only on getting something working as quickly possible. He said that java is not concerned with getting something out the door as quickly as possible, it is concerned with building a scalable, dependable platform as quickly as possible (something to that effect).
When James says scalable, what he means, I believe, is that if you need to go from 10,000 users a day to 10,000,000 or more users a day, you can do so by putting in clusters of servers handling loads at different tiers. In the case of the banking application I worked on, this is elevant, because every Friday there are 10,000 people logged in simultaneously reading data from their bank accounts and it takes some planning to pull that off smoothly.
But I think James dismisses scripting languages a bit too quickly in calling them "prototyping" languages. If I can take an old crummy box that pales in comparison to my data center top-of-the-line machines, and get it to do a million database operations in less than 3 minutes, then just think about the implications of that. Over the course of a day, I think I can easily handle 1 million page views with database operations on a live box in a data center on a relatively cheap server. Just for fun, let's say that I do 1 million sales a day on my website at $1.00 each. That means that I could do $365 million in business on a cheap box in a data center over the course of the year. That isn't anything to sneeze at.
What would the code for that look like....well, for the most part exactly what I described for the 120-page scripting example above. It would display pages of dynamic data and have short action pages of inserts and updates to the database with a little text formatting thrown in.
What I take away from these examples and from years of experience is this: Most web software applications that need to be built today are squarely in the problem domain of a scripting language. Some applications are not, such as high transaction systems like stock exchanges and banking, but most of the time you don't have to worry about those scenarios. Understanding these principles and dilineations can be worth tens of thousands or millions of dollars to your business because they have an enormous effect on not only your costs but also your opportunities.
Although understanding these principles is important, you aren't out of the woods simply by knowing the differences between when to use a scripting language and when to use a language like Java. One problem area includes which scripting language to use: ASP, ASP 2.0, Ruby, Perl, PHP, Python, Cold Fusion, ..., etc. Other problem areas include whether to use frameworks or not, whether to use object-oriented features, which database to use and which features of that database to use, and how good your programmers are, because bad programmers can mess up any language or programming approach. Those questions and answers are out of the scope of this article but are also important to address.
Some recent events brought a lot of clarity to this argument, however. As my team and I prepared to develop a major application I decided it would be fun to revisit a test I did about 5 years ago, and compare Resin (a Java application server known to be one of the fastest on the market), to PHP. Five years ago I found that by simulating 50 simultaneous requests to applications with a Mysql back end database, that the server came under almost no load when using PHP, while the Java stuff not only used 50% of CPU and RAM, but also ran considerably slower (2-3 times).
And so a few weeks ago I grabbed an old box, probably around a 1.5 Gig Pentium box with maybe 500 Megs of Ram, and installed the latest RedHat Fedora Linux. I figured that since our data center boxes are much more powerful than this hardware, it would be a good test. I put a lot of thought into how I would benchmark the applications in Java and PHP under various scenarios, and I ran the first test under PHP. I created a 500 character block of text and inserted it into an empty database 1 million times. This took about 2 1/2 minutes and the server did show that it was feeling the load, although I can't remember exactly what the load was because I planned to do the test again and then document the results. Something to keep in mind is that I was running the desktop environment on the box rather than just using the command line and it seems that the desktop GUI takes a ton of processing power away from the computer on such old hardware, so there were a number of factors contributing to a less than optimal running environment for the PHP application--but it was still really fast.
I then asked our top Java engineer, who has written significant J2EE applications for years, to set up the java environment to do the same test as I did in PHP on that server. He said it would be just a few minutes. Well, 4-5 hours later he gave up on setting up the environment because there were some libraries missing when he tried installing the new Java 5.
Now this was not the intention of the test, to highlight that one of the differences between Java or other "Enterprise" develpment environments and scripting languages is the speed of getting set up to do work. It is interesting to note, however, that I used PHP out of the box and had it running a heavy test within a very short time.
How fast you get you environment up and running is not really central to the discussion of when and where to use Java or a scripting language, so let me return to that discussion.
Some of the many things that cloud the issue of whether to use a scripting language or a language like Java is the discussion of frameworks, design patterns, and object relational database mapping. These topics are a combination of both theory and best practices and tend to be driven largely by the academic realm of universities and classrooms. But after years of indoctrination both in the classroom and in the real world about the many frameworks and patterns and object-oriented programming techniques, let me compare and contrast applications written in both scripting languages and enterprise platforms in production scenarios.
One of the largest applications I ever built in a scripting language consisted of 120 dynamic pages. It was an intranet application used for many different departments and every page was needed (no redundancy). The processing for every page was very simple, similar to the actual needs of most web applications I have ever worked on. For every form, there was a corresponding block of processing code which would cliean up the data a bit and update some information in the database, and do it all in just a few lines of readable code.
One of the largest projects I have worked on in the java realm was a 300+ page online banking application. It had all the buzzwords, it used model/view/controller and it was multi-tiered with presentation, business, and database layers. Obviously it was a bit complicated to work on but everyone at the company felt that in a mere 6 months an average java developer could get around the software effectively enough to do things without having to ask others how anymore. Although I've expressed a little sarcasm, I'll be honest in saying that the software was actually very well architected.
So what does this all mean? Well, recently I read an article about the 10th anniversay of java and it featured an interview with James Gosling, the creator of Java. He was asked about his perception of scripting languages. He said something to the effect that java for web applications (J2EE) and scripting languages are different animals. He said in essence that scripting languages are great for protyping and getting an application out the door with an emphasis only on getting something working as quickly possible. He said that java is not concerned with getting something out the door as quickly as possible, it is concerned with building a scalable, dependable platform as quickly as possible (something to that effect).
When James says scalable, what he means, I believe, is that if you need to go from 10,000 users a day to 10,000,000 or more users a day, you can do so by putting in clusters of servers handling loads at different tiers. In the case of the banking application I worked on, this is elevant, because every Friday there are 10,000 people logged in simultaneously reading data from their bank accounts and it takes some planning to pull that off smoothly.
But I think James dismisses scripting languages a bit too quickly in calling them "prototyping" languages. If I can take an old crummy box that pales in comparison to my data center top-of-the-line machines, and get it to do a million database operations in less than 3 minutes, then just think about the implications of that. Over the course of a day, I think I can easily handle 1 million page views with database operations on a live box in a data center on a relatively cheap server. Just for fun, let's say that I do 1 million sales a day on my website at $1.00 each. That means that I could do $365 million in business on a cheap box in a data center over the course of the year. That isn't anything to sneeze at.
What would the code for that look like....well, for the most part exactly what I described for the 120-page scripting example above. It would display pages of dynamic data and have short action pages of inserts and updates to the database with a little text formatting thrown in.
What I take away from these examples and from years of experience is this: Most web software applications that need to be built today are squarely in the problem domain of a scripting language. Some applications are not, such as high transaction systems like stock exchanges and banking, but most of the time you don't have to worry about those scenarios. Understanding these principles and dilineations can be worth tens of thousands or millions of dollars to your business because they have an enormous effect on not only your costs but also your opportunities.
Although understanding these principles is important, you aren't out of the woods simply by knowing the differences between when to use a scripting language and when to use a language like Java. One problem area includes which scripting language to use: ASP, ASP 2.0, Ruby, Perl, PHP, Python, Cold Fusion, ..., etc. Other problem areas include whether to use frameworks or not, whether to use object-oriented features, which database to use and which features of that database to use, and how good your programmers are, because bad programmers can mess up any language or programming approach. Those questions and answers are out of the scope of this article but are also important to address.
Friday, April 29, 2005
Computer Associates advertising
I just saw an advertisement for CA, where it discussed the boot time of computers, saying that computers infected with spyware can take 14 minutes to boot. I had to laugh at their attempt to mislead people for a variety of reasons.
First off, a lot of people still run Windows 2000. I recently spent a couple days trying to tweak all the performance I could out of my laptop. If I recall correctly, a fresh intall of Windows 2000 with no software installed required somewhere between 30 seconds and 1 minute to boot. After the Microsoft updates it took about 5 minutes to boot. After installing Norton Antivirus, the latest version, it took about 15 minutes to boot.
Based on that alone, it is misleading to suggest that an average boot time for a computer is being caused by spyware. That isn't to say spyware isn't a huge problem, but it is clear Computer Associates is being shady in their advertising.
That shouldn't be too surprising, however. Here in Utah I have worked with people that have worked in many levels of Computer Associates, and the integrity level of so many people in their corporate culture is abysmal. That is just their Utah office. On a higher corporate level it seems like they are rocked with scandal and dishonesty every year.
For my part, I can't imagine ever buying a CA product. I trust that there are honest engineers who work there, but they are so rife with dishonesty that it is just a risk to get involved with any of them.
As it relates to corporate culture, it is interesting that some companies, like AT&T, churn out people who have so much integrity that you could trust them with the keys to your house.
One last thought to wrap up. Regarding the original issue of why computers slow down, my colleagues and I have mused over that a bit. Honestly, my computer habits haven't changed much in 8 years. The majority of my computer use is using a word processor, email, and viewing the text on some websites. All of these things used to be smokingly fast on a Pentium 100 computer. It is strange to consider that the computers, doing the same tasks, become so poor at them now and the usefulness of the computers hasn't increased much despite the fact my computer is 20 times more powerful. One thing my colleagues and I have postulated is that Windows software has an algorithm that tells a computer to boot 50% slower and run 50% as fast for each year that passes, until it gets to a certain year when it calls a function that is called "hahahahupgrade()"
First off, a lot of people still run Windows 2000. I recently spent a couple days trying to tweak all the performance I could out of my laptop. If I recall correctly, a fresh intall of Windows 2000 with no software installed required somewhere between 30 seconds and 1 minute to boot. After the Microsoft updates it took about 5 minutes to boot. After installing Norton Antivirus, the latest version, it took about 15 minutes to boot.
Based on that alone, it is misleading to suggest that an average boot time for a computer is being caused by spyware. That isn't to say spyware isn't a huge problem, but it is clear Computer Associates is being shady in their advertising.
That shouldn't be too surprising, however. Here in Utah I have worked with people that have worked in many levels of Computer Associates, and the integrity level of so many people in their corporate culture is abysmal. That is just their Utah office. On a higher corporate level it seems like they are rocked with scandal and dishonesty every year.
For my part, I can't imagine ever buying a CA product. I trust that there are honest engineers who work there, but they are so rife with dishonesty that it is just a risk to get involved with any of them.
As it relates to corporate culture, it is interesting that some companies, like AT&T, churn out people who have so much integrity that you could trust them with the keys to your house.
One last thought to wrap up. Regarding the original issue of why computers slow down, my colleagues and I have mused over that a bit. Honestly, my computer habits haven't changed much in 8 years. The majority of my computer use is using a word processor, email, and viewing the text on some websites. All of these things used to be smokingly fast on a Pentium 100 computer. It is strange to consider that the computers, doing the same tasks, become so poor at them now and the usefulness of the computers hasn't increased much despite the fact my computer is 20 times more powerful. One thing my colleagues and I have postulated is that Windows software has an algorithm that tells a computer to boot 50% slower and run 50% as fast for each year that passes, until it gets to a certain year when it calls a function that is called "hahahahupgrade()"
Friday, January 21, 2005
Xp - Extreme Programming: When it shouldn't be used
One of the premises of extreme programming is that you use it when working on new software with rapidly changing requirements.
Anyone who has ever done development understands the chaos that changing requirements brings. But if you actually plan to live in an environment of rapidly changing requirements, you might want to reconsider your job.
Think about that type of mentality in other professions. Can you imagine building skyscrapers to changing specifications? Or a car? Or the parts of a movie (its a cartoon, no, it's claymation, no, it is a drama)?
I actually worked on a mansion once in the construction trade that was "cost plus", meaning that the specifications could change at any time. And they did, all the time. And at the end of the project they got a house that cost 3 times as much as the one next door even though it was comparable and it is structurally flawed and the foundation is unstable.
The fact is that stupidity and chaos is not a modern invention, it has been around since the beginning of time. To some extent waste is a byproduct is experimentation and is essential, but not everything in life should be an experiment when there are ample procedures that bring positive, proven results.
Think about what rapidly changing requirements means. It means, on an extreme level, that you don't know what you are building. It is one thing to allow for requirement flexibility on minor things, for instance allowing that the colors on a page might end up being blue or green. It is another to say I might be building a stock trading application or a property management application, but "I'm not really sure".
It is true that every product has revisions, but that is okay. It is okay to make accounting software that exports to a new format. It is okay to have accounting software that adds a new tax form. These are incremental updates, not huge architectural changes. It is not okay to start work on accounting software without having a solid idea of what the first product is going to be. Even if the client is willing to pay you cost-plus, you will likely end up with egg on your face.
A project manager really needs to have the guts to say that if the project requirements are not possible to nail down to a large degree, they won't work on the project.
A company hiring an IT team need to understand that if they don't know what they are trying to build in specific detail, they shouldn't even start.
Friday, January 14, 2005
Software without bugs: developers tell me it is impossible
Recently I was speaking to a developer who was astounded mentioned a site I had built, a 120 page website, all dynamic (database driven), and there were no bugs in it.
For most developers, that is one of the craziest things they have ever heard in their lives. After all, they are brilliant, and their project managers (if they have them) work 60-80 hours a week, so if they can't do it, nobody else can.
The application I worked on was not trivial, it supports significant functionality for a company that is the largest in the world in its market, and they had over 1000 employees at their height.
I have consulted for many companies over the years, and one thing that stands out to me most is that the success or failure of any project seems to hinge on the skillset of the project manager (and not the amount of hours they put into their jobs).
Agile methodologies and Extreme programming seem to go in the wrong direction in terms of solving the problem of creating software that arrives on time and without bugs. Adaptability is not the key to success in a programming project, but rather understanding of the problem at hand. Sometimes it requires attention to thousands (or tens of thousands) of details, but for people properly trained in simple techniques, even the most difficult projects can be successful, without bugs, and on time.
The truth about software development is that it shares a lot with building, but formal processes have been in place in the construction trade (like drawing proper blueprints) for a long time that are not in place for the software industry. In fact, the proliferation of tools and methodologies rapidly outpaces anyone's ability to even keep up with them.
For now, there will continue to be billions of dollars wasted in failed IT projects each year, but someday the dust willsettle and certain practices that work best will dominate.
For most developers, that is one of the craziest things they have ever heard in their lives. After all, they are brilliant, and their project managers (if they have them) work 60-80 hours a week, so if they can't do it, nobody else can.
The application I worked on was not trivial, it supports significant functionality for a company that is the largest in the world in its market, and they had over 1000 employees at their height.
I have consulted for many companies over the years, and one thing that stands out to me most is that the success or failure of any project seems to hinge on the skillset of the project manager (and not the amount of hours they put into their jobs).
Agile methodologies and Extreme programming seem to go in the wrong direction in terms of solving the problem of creating software that arrives on time and without bugs. Adaptability is not the key to success in a programming project, but rather understanding of the problem at hand. Sometimes it requires attention to thousands (or tens of thousands) of details, but for people properly trained in simple techniques, even the most difficult projects can be successful, without bugs, and on time.
The truth about software development is that it shares a lot with building, but formal processes have been in place in the construction trade (like drawing proper blueprints) for a long time that are not in place for the software industry. In fact, the proliferation of tools and methodologies rapidly outpaces anyone's ability to even keep up with them.
For now, there will continue to be billions of dollars wasted in failed IT projects each year, but someday the dust willsettle and certain practices that work best will dominate.
Wednesday, January 12, 2005
Micosoft vs Linux
Last year I was speaking with an IT manager and we discussed the question of our time: Microsoft vs. Linux
When he asked which camp I was in, I said that any person involved with Microsoft technologies needed to be very careful.
He said that was very interesting because stockholders tend to approve of Microsoft product rollouts at companies while IT managers are often reluctant.
The argument between which of the two technologies to use has two parts. Many people think that cost is the big issue, and ultimately that is the case, but the argument is best broken down into two parts: functionality and risk.
Functionally, you can accomplish anything that matters in the real world without a Microsoft product. For instance, if I am building web applications, I can use Cold Fusion, PHP, or Java (among others) as easily as ASP. They all accomplish the exact same thing. If I am building a desktop application, I can use Delphi or Java, among other environments, rather than Visual Basic or C++. If I need a web server, I can use Apache rather than IIS. If I need mail services I can use sendmail, postfix, Lotus Domino, or qmail rather than Exchange. And so on for every important type ofsoftware in use today.
So if you can accomplish every task without Microsoft products that you can with them, which should you use? The answer is it depends on the skillset of the people you have hired. Unless you are weighing other factors, it usually doesn't makesense to spend 6-12 months retraining employees to use a competitive technology when they already know one. Think about it, if your entry level programmer is making 50K or so, and you have a couple of them and want to retrain them from ASP toPHP, 100K of lost productivity probably isn't worth the benefit of avoiding a few thousand dollars of Microsoft server licensing costs.
The other important factor in determining whether or not to use Microsoft products is risk. A few years ago when Office 97was current, I could get it for $30.00 on eBay. Currently, because of an increase in sales price, the cheapest I can get Office XP is $175 on eBay. And Office 2003 costs $499 on Microsoft's site. For 99% of users out there, the features that they use have not changed in 8 years. Most end users do some basic Word processing, some basic Powerpoints, but they pay infinitely more to do those same tasks because competitors have been squeezed out of the market and you have to upgrade for "compatibility" with other users.
Common practices of Microsoft include frequent updates that break compatibility with competing products, participating in softwarepiracy policing and promising not to prosecute the accused if they promise to take competing products off of their computers,bogus research findings, and even paying for the sabatoge of competitor technology by inside employees in some cases (sounds like a movie but fact is sometimes more surprising than fiction).
At the end of the day, the risk that exists is that a company invests millions of dollars into developing a software infrastructurethat costs a fortune to maintain because of things like the old operating system is no longer being supported and large upgrade fees since the competitors are gone. In contrast, a Perl application written 10 years ago that supports an entire enterprise can be ported to a new computer within hours for very little platform cost.
As an experienced developer, I understand I can give exceptions to the trends outlined above, but overall they are valid issues and ones that individuals with significant and broad management and development experience will recognize.
Degan Kettles
President
Enterprise Consulting Group
http://www.enterpriseconsultinggroup.us
Wednesday, January 05, 2005
Delta Air Lines - Find airline tickets, manage your SkyMiles account, or check flight schedules
Delta Air Lines - Find airline tickets, manage your SkyMiles account, or check flight schedules
Delta is a huge disappointment today. After driving like a madman through an unexpected snowstorm, I try to get my boarding pass for a flight which didn't even board until 45 minutes after I was at the airport, and they gave me the run around until they started boarding and said they couldn't get me a boarding pass then. It turns out they had oversold my flight, and they had no flights available the rest of the day. Their website doesn't come up today and their 800 number has given a busy signal all day long. All the while I miss out on a huge business meeting for which many people were flying in. All I got was an "I can't do anything" from Delta ticketing employees. The worst part is knowing that I was there in plenty of time to get on the flight that I paid for and I couldn't get on it.
Degan Kettles
President
Enterprise Consulting Group
http://www.enterpriseconsultinggroup.us
Delta is a huge disappointment today. After driving like a madman through an unexpected snowstorm, I try to get my boarding pass for a flight which didn't even board until 45 minutes after I was at the airport, and they gave me the run around until they started boarding and said they couldn't get me a boarding pass then. It turns out they had oversold my flight, and they had no flights available the rest of the day. Their website doesn't come up today and their 800 number has given a busy signal all day long. All the while I miss out on a huge business meeting for which many people were flying in. All I got was an "I can't do anything" from Delta ticketing employees. The worst part is knowing that I was there in plenty of time to get on the flight that I paid for and I couldn't get on it.
Degan Kettles
President
Enterprise Consulting Group
http://www.enterpriseconsultinggroup.us
Subscribe to:
Posts (Atom)