When looking for employment you should keep in mind the needs of potential employers. Of course you want the job – but what do employers want from you?
1. Loyalty – Loyal employees are the backbone of any organization. Look at your resume (or LinkedIn profile), does your work history seem like that of a loyal employee? If there are short term roles listed make it clear they were temporary jobs. Jobs not relevant to the role can be omitted. At interview do not gossip or share details of previous employers, colleagues or mutual acquaintances – indulging in tittle-tattle will make you appear disloyal.
2. Honesty – Employers need to be able to trust you. Never pad you resume, be honest about qualifications and experience. Nothing is more likely to make you appear dishonest than being caught in a half truth at interview.
3. Punctuality – Bosses need to know their workers will be at their posts on time every day as poor timekeeping can cost a company customers. Demonstrate good timekeeping by turning in your application form on time. If given an interview appointment make sure you arrive at least ten minutes in advance of you allotted time.
4. Determination – People who want to do well are much more likely to work with passion and gain results for their employers. When given the chance to question a potential employer at interview, don’t be afraid to ask about opportunities for advancement, as this will display determination and alert the interviewer to your desire to succeed.
5. Flexibility – The ever changing face of business means employers need workers who are willing to move with the times, adapting to the evolving demands of their role. Use your application form to demonstrate how you have been flexible in previous roles – if you took on extra responsibilities or undertook additional training make sure you let them know.
6. Smart Appearance – Whether you will be working in a formal or casual environment, it is important to take care with your appearance at interview. If you look scruffy employers may ignore your skills, assuming that someone who doesn’t take pride in themselves will be unlikely to take pride in their work.
7. Positive Outlook – Employers want go-getters on their team. Showing a positive outlook at interview is essential. If you have been made redundant from a previous role, don’t bemoan your fate to a potential boss, instead explain how excited you are to be exploring new opportunities.
8. Communications Skills – Communication skills are key. Ensure your application and resume are grammatically correct, ask a friend or family to look them over for you to help catch any typos or errors. At interview think before you speak, choose your words carefully and ensure they convey the message clearly. Don’t “um” and “ah” – it is better to take a few seconds to compose an answer than to say something stupid.
Demonstrating these eight key skills can help you land your dream role, and displaying these traits in your daily working life will make you stand out over other employees when the opportunity for advancement arises.
Monday, November 29, 2010
Saturday, November 20, 2010
Filesystem Utilization Korn Shell Script
Script will run in cron @ 6,8,10,12am and 2,4pm to check filesystems that are above 90% full.
95% is the percentage used across the board unless otherwise noted.
export PG1=555555555@pager.net
export PG2=555555555@pager.net
df -k | grep -iv -e filesystem -e /var/nim/resources -e proc -e cd -e /var/mksysbs -e /usr | awk '{ print $7" "$4}' | while read LINE
do
FILESYSTEM=`echo $LINE | cut -d"%" -f1 | awk '{ print $1 }'`
PERCENTAGE=`echo $LINE | cut -d"%" -f1 | awk '{ print $2 }'`
if [ $PERCENTAGE -ge 95 ]; then
echo "The system `hostname` has caused a filesystem alert on `date`. The ${FILESYSTEM} is ${PERCENTAGE}% full. \\n You will recieve this message every 2 hours until either the problem is corrected or the root crontab entry is commented out.[dfchk.sh] \\n \\n " | mail -s "- $FILESYSTEM is at $PERCENTAGE " $AD1 $PG1 #$PG2
fi
done
95% is the percentage used across the board unless otherwise noted.
#!/bin/ksh
#######################################################################################################
# Created: Javier Blanco
# Creation Date: 11/06/2001
# Use: By all unix servers
# Description: Script will run in cron @ 6,8,10,12am and 2,4pm to check filesystems that are
# above 90% full.
# 95% is the percentage used across the board unless otherwise noted.
#
########################################################################################################
export AD1=unixadmins@xyz.comexport PG1=555555555@pager.net
export PG2=555555555@pager.net
df -k | grep -iv -e filesystem -e /var/nim/resources -e proc -e cd -e /var/mksysbs -e /usr | awk '{ print $7" "$4}' | while read LINE
do
FILESYSTEM=`echo $LINE | cut -d"%" -f1 | awk '{ print $1 }'`
PERCENTAGE=`echo $LINE | cut -d"%" -f1 | awk '{ print $2 }'`
if [ $PERCENTAGE -ge 95 ]; then
echo "The system `hostname` has caused a filesystem alert on `date`. The ${FILESYSTEM} is ${PERCENTAGE}% full. \\n You will recieve this message every 2 hours until either the problem is corrected or the root crontab entry is commented out.[dfchk.sh] \\n \\n " | mail -s "- $FILESYSTEM is at $PERCENTAGE " $AD1 $PG1 #$PG2
fi
done
High Availability and Hardware Availability
High availability is sometimes confused with simple hardware availability. Fault tolerant, redundant systems (such as RAID) and dynamic switching technologies (such as DLPAR) provide recovery of certain hardware failures, but do not provide the full scope of error detection and recovery required to keep a complex application highly available.
A modern, complex application requires access to all of these components:
Recent surveys of the causes of downtime show that actual hardware failures account for only a small percentage of unplanned outages. Other contributing factors include:
Reliable and recoverable hardware simply cannot protect against failures of all these different aspects of the configuration. Keeping these varied elements—and therefore the application— highly available requires:
High availability vs. fault tolerance
The difference between fault tolerance and high availability, is this: A fault tolerant environment has no service interruption but a significantly higher cost, while a highly available environment has a minimal service interruption.
Fault tolerance relies on specialized hardware to detect a hardware fault and instantaneously switch to a redundant hardware component—whether the failed component is a processor, memory board, power supply, I/O subsystem, or storage subsystem. Although this cutover is apparently seamless and offers non-stop service, a high premium is paid in both hardware cost and performance because the redundant components do no processing. More importantly, the fault tolerant model does not address software failures, by far the most common reason for downtime.
High availability views availability not as a series of replicated physical components, but rather as a set of system-wide, shared resources that cooperate to guarantee essential services. High availability combines software with industry-standard hardware to minimize downtime by quickly restoring essential services when a system, component, or application fails. While not instantaneous, services are restored rapidly, often in less than a minute.
Many sites are willing to absorb a small amount of downtime with high availability rather than pay the much higher cost of providing fault tolerance. Additionally, in most highly available configurations, the backup processors are available for use during normal operation.
High availability systems are an excellent solution for applications that must be restored quickly and can withstand a short interruption should a failure occur. Some industries have applications so time-critical that they cannot withstand even a few seconds of downtime. Many other industries, however, can withstand small periods of time when their database is unavailable.
A modern, complex application requires access to all of these components:
- Nodes (CPU, memory)
- Network interfaces (including external devices in the network topology)
- Disk or storage devices.
Recent surveys of the causes of downtime show that actual hardware failures account for only a small percentage of unplanned outages. Other contributing factors include:
- Operator errors
- Environmental problems
- Application and operating system errors.
Reliable and recoverable hardware simply cannot protect against failures of all these different aspects of the configuration. Keeping these varied elements—and therefore the application— highly available requires:
- Thorough and complete planning of the physical and logical procedures for access and operation of the resources on which the application depends. These procedures help to avoid failures in the first place.
- A monitoring and recovery package that automates the detection and recovery from errors.
- A well-controlled process for maintaining the hardware and software aspects of the cluster configuration while keeping the application available.
High availability vs. fault tolerance
The difference between fault tolerance and high availability, is this: A fault tolerant environment has no service interruption but a significantly higher cost, while a highly available environment has a minimal service interruption.
Fault tolerance relies on specialized hardware to detect a hardware fault and instantaneously switch to a redundant hardware component—whether the failed component is a processor, memory board, power supply, I/O subsystem, or storage subsystem. Although this cutover is apparently seamless and offers non-stop service, a high premium is paid in both hardware cost and performance because the redundant components do no processing. More importantly, the fault tolerant model does not address software failures, by far the most common reason for downtime.
High availability views availability not as a series of replicated physical components, but rather as a set of system-wide, shared resources that cooperate to guarantee essential services. High availability combines software with industry-standard hardware to minimize downtime by quickly restoring essential services when a system, component, or application fails. While not instantaneous, services are restored rapidly, often in less than a minute.
Many sites are willing to absorb a small amount of downtime with high availability rather than pay the much higher cost of providing fault tolerance. Additionally, in most highly available configurations, the backup processors are available for use during normal operation.
High availability systems are an excellent solution for applications that must be restored quickly and can withstand a short interruption should a failure occur. Some industries have applications so time-critical that they cannot withstand even a few seconds of downtime. Many other industries, however, can withstand small periods of time when their database is unavailable.
Thursday, November 11, 2010
Caché System Failover Strategies
Caché fits into all common high-availability configurations supplied by operating system providers including Microsoft,IBM, HP, and EMC. Caché provides easy-to-use, often automatic, mechanisms that integrate easily with the operating system to provide high availability.There are four general approaches to system failover. In order of increasing availability they are:
• No Failover Strategy
• Failover Cluster
• Concurrent Cluster
• ECP Cluster
There are variations on these strategies; for example, many large enterprise clients have implemented ECP cluster and alsouse failover cluster for disaster recovery.It is important to differentiate between failover and disaster recovery. Failover is a methodology to resume system availability
in an acceptable period of time, while disaster recovery is a methodology to resume system availability when allfailover strategies have failed.
No Failover Strategy
With no failover strategy in place your Caché database integrity is still protected from production system failure. Structural database integrity is maintained by Caché write image journal (WIJ) technology; you cannot disable this. Logical integrity is maintained through global journaling and transaction processing. While global journaling can be disabled and transaction processing is optional, InterSystems highly recommends using them.
If a production system failure occurs, such as a hardware failure, the database and application are generally unaffected. Disk degradation, of course, is an exception. Disk redundancy and good backup procedures are vital to mitigate problems arising from disk failure.
Failover Cluster
A common and often inexpensive approach to recovery after failure is to maintain a standby system to assume the production workload in the event of a production system failure. A typical configuration has two identical computers with shared access to a disk subsystem.
After a failure, the standby system takes over the applications formerly running on the failed system. Microsoft Windows Clusters, HP MC/ServiceGuard, Tru64 UNIX® TruClusters, OpenVMS Clusters, and IBM HACMP provide a common approach for implementing failover cluster. In these technologies, the standby system senses a heartbeat from the production
system on a frequent and regular basis. If the heartbeat consistently stops for a period of time, the standby system automatically assumes the IP address and the disk formerly associated with the failed system. The standby can then run any applications (Caché, for example) that were on the failed system. In this scenario, when the standby system takes over the application, it executes a pre-configured start script to bring the databases online. Users can then reconnect to the databases that are now running on the standby server. Again, WIJ, global journaling, and transaction processing are used to maintain structural and data integrity.
To be continued
• No Failover Strategy
• Failover Cluster
• Concurrent Cluster
• ECP Cluster
There are variations on these strategies; for example, many large enterprise clients have implemented ECP cluster and alsouse failover cluster for disaster recovery.It is important to differentiate between failover and disaster recovery. Failover is a methodology to resume system availability
in an acceptable period of time, while disaster recovery is a methodology to resume system availability when allfailover strategies have failed.
No Failover Strategy
With no failover strategy in place your Caché database integrity is still protected from production system failure. Structural database integrity is maintained by Caché write image journal (WIJ) technology; you cannot disable this. Logical integrity is maintained through global journaling and transaction processing. While global journaling can be disabled and transaction processing is optional, InterSystems highly recommends using them.
If a production system failure occurs, such as a hardware failure, the database and application are generally unaffected. Disk degradation, of course, is an exception. Disk redundancy and good backup procedures are vital to mitigate problems arising from disk failure.
Failover Cluster
A common and often inexpensive approach to recovery after failure is to maintain a standby system to assume the production workload in the event of a production system failure. A typical configuration has two identical computers with shared access to a disk subsystem.
After a failure, the standby system takes over the applications formerly running on the failed system. Microsoft Windows Clusters, HP MC/ServiceGuard, Tru64 UNIX® TruClusters, OpenVMS Clusters, and IBM HACMP provide a common approach for implementing failover cluster. In these technologies, the standby system senses a heartbeat from the production
system on a frequent and regular basis. If the heartbeat consistently stops for a period of time, the standby system automatically assumes the IP address and the disk formerly associated with the failed system. The standby can then run any applications (Caché, for example) that were on the failed system. In this scenario, when the standby system takes over the application, it executes a pre-configured start script to bring the databases online. Users can then reconnect to the databases that are now running on the standby server. Again, WIJ, global journaling, and transaction processing are used to maintain structural and data integrity.
To be continued
Wednesday, August 04, 2010
A New Era Started Today
Finally made the decision of buying a Digital SLR camera. After months of tedious research I narrowed my choice to the Canon EOS 7D. It's final! I ordered the 7D from Buyer Edge, an online retailer located in New Jersey. The setup is simple: Just the camera for now.
Friday, June 08, 2007
MIT team lights it up -- without wires
The latest MIT news flash could finally allow consumers to cut their power cords: A Massachusetts Institute of Technology research team has figured out how to wirelessly illuminate an unplugged light bulb from seven feet away.
Within the next five years, MIT physicist Marin Soljacic foresees a day when people could forgo the tangle of wires that keeps laptop, iPod, and cellphone users on a short leash. Instead, they could use a carefully designed magnetic field to deliver power to devices over the air. "At this point, this is a proof of principle -- the main point of our research was to see if we could transfer energy wirelessly," said Soljacic, who was inspired by the annoying beeps his cellphone made in the middle of the night when he forgot to charge it. "It occurred to me that it would be so great if the thing took care of its own charging."
Details about WiTricity, or wireless electricity, were reported yesterday in Science Express, an online publication of the journal Science.
In the demonstration, Soljacic and his team generated a magnetic field on one copper coil. Seven feet away, a similar coil specially tuned to resonate with the field received enough power to light up a 60-watt bulb. Typically, a laptop requires about 30 to 40 watts, he said, and an iPod or cellphone might require a few watts.
Already, some products have been developed that allow consumers to wirelessly charge their devices over very short distances.
But if Soljacic's idea bears fruit, consumers could be truly unplugged -- their rechargers and bulky adapters replaced by a device that transmits power wirelessly. The Army Research Office, the National Science Foundation, and the Department of Energy funded his research.
Within the next five years, MIT physicist Marin Soljacic foresees a day when people could forgo the tangle of wires that keeps laptop, iPod, and cellphone users on a short leash. Instead, they could use a carefully designed magnetic field to deliver power to devices over the air. "At this point, this is a proof of principle -- the main point of our research was to see if we could transfer energy wirelessly," said Soljacic, who was inspired by the annoying beeps his cellphone made in the middle of the night when he forgot to charge it. "It occurred to me that it would be so great if the thing took care of its own charging."
Details about WiTricity, or wireless electricity, were reported yesterday in Science Express, an online publication of the journal Science.
In the demonstration, Soljacic and his team generated a magnetic field on one copper coil. Seven feet away, a similar coil specially tuned to resonate with the field received enough power to light up a 60-watt bulb. Typically, a laptop requires about 30 to 40 watts, he said, and an iPod or cellphone might require a few watts.
Already, some products have been developed that allow consumers to wirelessly charge their devices over very short distances.
But if Soljacic's idea bears fruit, consumers could be truly unplugged -- their rechargers and bulky adapters replaced by a device that transmits power wirelessly. The Army Research Office, the National Science Foundation, and the Department of Energy funded his research.
Saturday, June 02, 2007
It's All About Process
As long ago as 1931, the distinguished American economist, William Edwards Deming said that "If you can't describe what you are doing as a process, you don't know what you're doing!"
In IT today it is still difficult to describe how a business requirement ends up as part of a functioning business service. This is almost never written down as a single contiguous process. At best we seek to articulate this across several different process methodologies, at worst we recognize no process methodology at all and re-invent the wheel with each new business development.
In IT it is essential that we should know what we are doing. It is equally essential that we should know, record and understand what we have done and how we did it. This is the essence of balanced control with good governance and to achieve this we need to ensure that we follow a defined, consistent and repeatable process.
Process is there to help people and it has some very important attributes that are essential to the delivery of quality IT Services.
A most significant attribute of good process is that it is measurable against industry accepted criteria or standards. When a process methodology refers to certification at a given level, or to compliance with an industry standard then this is usually a result of independent audit and assessment.
Enterprise application integration
In today’s competitive and dynamic business environment, applications such as Supply Chain Management, Customer Relationship Management, Business Intelligence and Integrated Collaboration environments have become imperative for organizations that need to maintain their competitive advantage. Enterprise Application Integration (EAI) is the process of linking these applications and others in order to realize financial and operational competitive advantages.
When different systems can’t share their data effectively, they create information bottlenecks that require human intervention in the form of decision making or data entry. With a properly deployed EAI architecture, organizations are able to focus most of their efforts on their value-creating core competencies instead of focusing on workflow management.
For generations, systems have been built that have served a single purpose for a single set of users without sufficient thought to integrating these systems into larger systems and multiple applications. EAI is the solution to the unanticipated outcome of generations of development undertaken without a central vision or strategy. The demand of the enterprise is to share data and processes without having to make sweeping changes to the applications or data structures. Only by creating a method of accomplishing this integration can EAI be both functional and cost-effective.
One of the challenges facing modern organizations is giving all their workers complete, transparent and real-time access to information. Many of the legacy applications still in use today were developed using arcane and proprietary technologies, thus creating information silos across departmental lines within organizations. These systems hampered seamless movement of information from one application to the other. EAI, as a discipline, aims to alleviate many of these problems, as well as create new paradigms for truly lean proactive organizations. EAI intends to transcend the simple goal of linking applications, and attempts to enable new and innovative ways of leveraging organizational knowledge to create further competitive advantages for the enterprise.
EAI is a response to decades of creating distributed monolithic, single purpose applications leveraging a hodgepodge of platforms and development approaches. EAI represents the solution to a problem that has existed since applications first moved from central processors. Put briefly, EAI is the “unrestricted sharing of data and business processes among any connected application or data sources in the enterprise.”
Undoubtedly, there are a number of instances of stovepipe systems in an enterprise, such as inventory control systems, sales automation systems, general ledger systems, and human resource systems. These systems typically were custom-built with specific needs in mind, utilizing the technology.
When different systems can’t share their data effectively, they create information bottlenecks that require human intervention in the form of decision making or data entry. With a properly deployed EAI architecture, organizations are able to focus most of their efforts on their value-creating core competencies instead of focusing on workflow management.
For generations, systems have been built that have served a single purpose for a single set of users without sufficient thought to integrating these systems into larger systems and multiple applications. EAI is the solution to the unanticipated outcome of generations of development undertaken without a central vision or strategy. The demand of the enterprise is to share data and processes without having to make sweeping changes to the applications or data structures. Only by creating a method of accomplishing this integration can EAI be both functional and cost-effective.
One of the challenges facing modern organizations is giving all their workers complete, transparent and real-time access to information. Many of the legacy applications still in use today were developed using arcane and proprietary technologies, thus creating information silos across departmental lines within organizations. These systems hampered seamless movement of information from one application to the other. EAI, as a discipline, aims to alleviate many of these problems, as well as create new paradigms for truly lean proactive organizations. EAI intends to transcend the simple goal of linking applications, and attempts to enable new and innovative ways of leveraging organizational knowledge to create further competitive advantages for the enterprise.
EAI is a response to decades of creating distributed monolithic, single purpose applications leveraging a hodgepodge of platforms and development approaches. EAI represents the solution to a problem that has existed since applications first moved from central processors. Put briefly, EAI is the “unrestricted sharing of data and business processes among any connected application or data sources in the enterprise.”
Undoubtedly, there are a number of instances of stovepipe systems in an enterprise, such as inventory control systems, sales automation systems, general ledger systems, and human resource systems. These systems typically were custom-built with specific needs in mind, utilizing the technology.
Thursday, February 15, 2007
Wednesday, April 26, 2006
Seagate announces 750GB hard drive
As I was writing my previous post regarding my defunct 20MB Kyocera hard drive, I received news of a technological breakthrough regarding hard drives. Segate has introduced the Barracuda 7200.10 family, built on perpendicular recording. The first drive will have 750GB capacity and will sell for $559.
Read the news release
Read the news release
IBM PS/2 Problems
I decided to work on my IBM PS/2 Model 30 computer over the weekend, and to my surprise I started having problems with the system's 20MB hard drive. I ran DOS 6.22 Scandisk only to find out lots of bad clusters. The hard drive had reach the end of its life. Here are some details about this drive:
- Brand: Kyocera
- Model: KC-20B
- Capacity: 21.4MB
- Access Time: 65 ms
- Rated Voltage: 12v,5v
- Serial Number: KB2089589
- In Operation since: December 1988
- Interface: MFM (Modified Frequency Modulation, yes way before IDE drives)
This is a memorable little drive from a company that has long since exited the business. These days, Kyocera are a major manufacturer of laser printers, but it's a long, long time since they made a hard drive. Still, at least with this particular model Kyocera were obviously successful as a drive manufacturer: KC-20s were quite common in their day and remained around as valuable trade-ins well into the early Nineties.
Like so many early drives, you could recognise the KC-20 by sound alone — something you almost never get with modern drives. The sweet little high-pitched pinging noise the Kyocera's seek mechanism made was unique. In practical terms, the drives themselves were nothing out of the ordinary: reasonably reliable as MFM drives went, a little on the sluggish side, not very different to a half-dozen others of the same vintage. Good bye friend!
More information on MFM technology http://en.wikipedia.org/wiki/Modified_Frequency_Modulation
Apple Introduces 17-inch MacBook Pro
Apple unveiled its new 17-inch MacBook Pro notebook computer featuring the Intel Core Duo processor and an all new system architecture that delivers up to five times the performance of the PowerBook G4. http://www.apple.com/macbookpro/
Friday, April 01, 2005
Shipping Software by Mark Lucovsky
A few weeks ago I had lunch with the now famous "Mark Jen". I never knew Mark while we were at Microsoft, even though we both worked in the same group. Funny how large groups at Microsoft can get...We had a great Google style lunch at a sunny table in Mountain View. I was too dense to notice that Mark was doing research for his blog. One thing he said got me thinking... Something that many have said over the years, that Microsoft "knows how to ship software". Being a 16 year Microsoft veteran, a Distinguished Engineer, key architect and code writer for windows, architect of the largest source code control and build system ever attempted, I deeply believed that Microsoft knows how to ship software. We know how to build it, test it, localize it, manufacture it, charge lots of $$$ for it, etc.Mark and I talked about this briefly at lunch that day, and I have been thinking about it from time to time since...I am not sure I believe anymore, that Microsoft "knows how to ship software".
When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? I know the answer and so do you... The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will "ship" meaning that CD's will be pressed and delivered to customers and OEM's. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date.
In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM...Consider the .NET framework for a second. Suppose you wrote something innocent like a screen saver, written in C# based on the .NET framework. How would you as an ISV "ship your software"? You can't. Not unless you sign up to ship Microsoft's software as well. You see, the .NET Framework isn't widely deployed. It is present on a small fraction of machines in the world. Microsoft built the software, tested it, released it to manufacturing. They "shipped it", but it will take years for it to be deployed widely enough for you, the ISV to be able to take advantage of it. If you want to use .NET, you need to ship Microsoft's software for them. Isn't this an odd state of affairs? Microsoft is supposed to be the one that "knows how to ship software", but you are the one doing all the heavy lifting. You are the one that has to ship their software the last mile, install it on end user machines, ensure their machines still work after you perform this platform level surgery.
When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software.I would argue that Microsoft used to know how to ship software, but the world has changed... The companies that "know how to ship software" are the ones to watch. They have embraced the network, deeply understand the concept of "software as a service", and know how to deliver incredible value to their customers efficiently and quickly.
When a Microsoft engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? I know the answer and so do you... The software sits in a source code control system for a minimum of two years (significantly longer for some of the early Longhorn code). At some point, the product that the fix is a part of will "ship" meaning that CD's will be pressed and delivered to customers and OEM's. In best case scenarios, the software will reach end users a few months after the Release To Manufacturing (RTM) date.
In many cases, particularly for users working in large corporations, they won't see the software for a year or more post RTM...Consider the .NET framework for a second. Suppose you wrote something innocent like a screen saver, written in C# based on the .NET framework. How would you as an ISV "ship your software"? You can't. Not unless you sign up to ship Microsoft's software as well. You see, the .NET Framework isn't widely deployed. It is present on a small fraction of machines in the world. Microsoft built the software, tested it, released it to manufacturing. They "shipped it", but it will take years for it to be deployed widely enough for you, the ISV to be able to take advantage of it. If you want to use .NET, you need to ship Microsoft's software for them. Isn't this an odd state of affairs? Microsoft is supposed to be the one that "knows how to ship software", but you are the one doing all the heavy lifting. You are the one that has to ship their software the last mile, install it on end user machines, ensure their machines still work after you perform this platform level surgery.
When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software.I would argue that Microsoft used to know how to ship software, but the world has changed... The companies that "know how to ship software" are the ones to watch. They have embraced the network, deeply understand the concept of "software as a service", and know how to deliver incredible value to their customers efficiently and quickly.
Subscribe to:
Posts (Atom)