My parents Windows machine was on its last legs. I suggested that they get a Mac for their next machine "because it's easier", and I believed it. They purchased an iMac and I set it up for them. They were very impressed with the all-in-one design, and some initial "oooo ahhh" moments with the integrated camera, microphone, speakers and slot loading optical drive.
That was about it.
Then it came time for them to do what they were used to doing on the Windows machine. Even though it took fewer clicks and let them do things in a more seamless fashion, the Mac UI was not the same as the Windows UI and they were easily confused.
Being able to make changes and then just close a window instead of having to click "Apply" and then confirm that you did in fact want the changes was not seen as easier. It was seen as unsettling.
Being able to just pop in a CD and have it ripped by iTunes was seen as inferior to inserting a CD and then playing it with Microsoft Media Player.
The list went on.
I got them all set up for e-mail, browsing, pictures, music, etc. and have left them copious notes on how to do each task they want, and their home office looks much neater than it did previously with no more cord insanity, and the monitor is much nicer than their old one, but I am still nervous about them simply amusing me by taking up my suggestion.
My hope is that over time I have helped them with a good decision, but I thought it ironic that I did not take my own advice about being techgnostic about their technology setup. I am buying off my conscience by telling myself that the iMac will over the long run be much easier to use and less prone to viruses and such.
Hopefully I'm right.
Monday, April 14, 2008
Tuesday, April 1, 2008
Process
Process is kind of a loose word, where different people mean different things by it. When a process is broken, though, just stating that it is broken is useless. You have to describe WHAT about the process is broken, and why. Usually it is not very difficult to discover, but the piece that is broken is often there in order to make something easier for someone. It was not seen as a breakage, but just a short cut. Sometimes you can get away with one of these in a process, particularly when the process is long-running.
This is deceptive as people think "Well, that one little deviation did not hurt, one more won't hurt either." Soon the original deviation is one of many and the process breaks. Often there is a finger pointing exercise wherein everybody trots out their favorite theory of what went wrong, but the process remains broken. The deviations often have become the practice in the organization and people are invested in it.
Often an outsider is brought in to help "fix" the process.
Being an outsider, this person usually immediately sees where the problem is and tells everyone exactly what it is. Either the person is thanked and process is put back to a working state, or it is decided that the outsider does not "get it" and cannot understand the intricacies of how the organization works. Regardless of which result comes out of it, we can rest assured that the process will drift away from the ideal at some point. So, what can one do about it? Usually you have to have someone dedicated to a concept like "quality" where the process that is followed is periodically reviewed, and someone is held accountable for the worthiness of the process.
Many times this sort of function is seen as pure busywork of the worst kind, and a waste of effort. The time wasted every time the process breaks and profits or customers are lost more than make up for any investment in quality, but people will still make the short term decisions to save a few dollars.
In technology ventures, this whole "process" dance is even more vital as the processes are often automated and can occur thousands or millions of times before it becomes apparent that it is broken. Ironically, because of the fluid nature of software, process is given even shorter shrift than in real physical processes because you can often kludge something together to get to a short term goal. Inevitably you will pay for it later, with interest.
If you are involved in a technology project, regardless of vendor, platform, etc. be sure that you can describe your process for solving your problem in language that anybody could understand, and then be sure that you stick to it. I'm not saying never change the process, as they will evolve to meet changes, but if you cannot explain what you do, or how you accomplish your goals you are doomed to waste a lot of time and effort that could be used to help create more value from your technology investment.
This is deceptive as people think "Well, that one little deviation did not hurt, one more won't hurt either." Soon the original deviation is one of many and the process breaks. Often there is a finger pointing exercise wherein everybody trots out their favorite theory of what went wrong, but the process remains broken. The deviations often have become the practice in the organization and people are invested in it.
Often an outsider is brought in to help "fix" the process.
Being an outsider, this person usually immediately sees where the problem is and tells everyone exactly what it is. Either the person is thanked and process is put back to a working state, or it is decided that the outsider does not "get it" and cannot understand the intricacies of how the organization works. Regardless of which result comes out of it, we can rest assured that the process will drift away from the ideal at some point. So, what can one do about it? Usually you have to have someone dedicated to a concept like "quality" where the process that is followed is periodically reviewed, and someone is held accountable for the worthiness of the process.
Many times this sort of function is seen as pure busywork of the worst kind, and a waste of effort. The time wasted every time the process breaks and profits or customers are lost more than make up for any investment in quality, but people will still make the short term decisions to save a few dollars.
In technology ventures, this whole "process" dance is even more vital as the processes are often automated and can occur thousands or millions of times before it becomes apparent that it is broken. Ironically, because of the fluid nature of software, process is given even shorter shrift than in real physical processes because you can often kludge something together to get to a short term goal. Inevitably you will pay for it later, with interest.
If you are involved in a technology project, regardless of vendor, platform, etc. be sure that you can describe your process for solving your problem in language that anybody could understand, and then be sure that you stick to it. I'm not saying never change the process, as they will evolve to meet changes, but if you cannot explain what you do, or how you accomplish your goals you are doomed to waste a lot of time and effort that could be used to help create more value from your technology investment.
Thursday, March 27, 2008
On the road again...
I'm on the road this week, visiting another office for development meetings. I've been trying to post something on Mondays, Wednesdays and Fridays. The trip has been very busy and the only alone time I've had is when sleeping, so that schedule did not work. I have some downtime now, so I'll knock something out fast.
This trip has been an excellent illustration of the importance of communication. You can exchange e-mails all day with someone, or talk to them on the phone now and again, but nothing beats being there in person, face-to-face with someone. That kind of high bandwidth communication removes all kinds of barriers where things can be mis-read or lost in translation.
More things were decided in a few days of meetings than happened in months remotely. Yet, there is often a reluctance to incur the expense of travel. Penny wise, pound foolish.
This trip has been an excellent illustration of the importance of communication. You can exchange e-mails all day with someone, or talk to them on the phone now and again, but nothing beats being there in person, face-to-face with someone. That kind of high bandwidth communication removes all kinds of barriers where things can be mis-read or lost in translation.
More things were decided in a few days of meetings than happened in months remotely. Yet, there is often a reluctance to incur the expense of travel. Penny wise, pound foolish.
Friday, March 21, 2008
Good Enough Hardware
Used to be, a "cheap" desktop computer hovered around a thousand dollars in price, without a monitor. Those days are now far behind us. Cheap desktop systems with bundled LCD monitors are easily found for less than five hundred dollars. Laptops have similarly crashed in price, with a race for the bottom still underway. There is still a high end to the market, with multi-thousand dollar machines, but only people with very specific requirements should buy them.
If you only drive a few nails a year to hang pictures, you can buy a five dollar hammer and you're set. If you take that five dollar hammer onto a job site and drive a few thousand nails with it you will quickly destroy it, rounding the head of it, shredding the handle, etc. In the same way if you are a hard core video game player you would not buy a five hundred dollar computer and expect to be happy.
All that said, most people can get by with the modern "low end" computer, that has more processing power, memory, disk space, etc. than machines they purchased a few years ago. And that computer will be sufficient for a fairly long time. In the 90's software could get ahead of your computer very quickly, and your hardware quickly became obsolete. With so much time between major updates of software now, plus the power available at the low end of the market, breaks this cycle.
The one place that this is somewhat not true is with the Microsoft Vista operating system, if you want to run it with all the bells and whistles. If you want that then the low end machines might not be exactly what you want. If you are only wanting to surf the web and do e-mail you should consider alternative operating systems that run on the same hardware, such as a Linux distribution like Ubuntu.
The Macintosh computers are more expensive, but come loaded with a lot more bells and whistles that narrow the gap between the low end PC and the low end Mac. They offer a good level of stability and if you are looking for easy they are hard to beat.
When you go to purchase your next computer, consider all the factors, including what you are actually SPECIFICALLY going to use the machine for, and do not fall for the sales pitch of the latest, greatest and fastest. A "good enough" computer is going to be sufficient for 95% of people, so don't turn up your nose at a computer because of its low price. You'll be pleasantly surprised by your new machine, regardless.
Make your choice techgnostically, and don't be swayed by hype (I'm looking at YOU, Microsoft).
If you only drive a few nails a year to hang pictures, you can buy a five dollar hammer and you're set. If you take that five dollar hammer onto a job site and drive a few thousand nails with it you will quickly destroy it, rounding the head of it, shredding the handle, etc. In the same way if you are a hard core video game player you would not buy a five hundred dollar computer and expect to be happy.
All that said, most people can get by with the modern "low end" computer, that has more processing power, memory, disk space, etc. than machines they purchased a few years ago. And that computer will be sufficient for a fairly long time. In the 90's software could get ahead of your computer very quickly, and your hardware quickly became obsolete. With so much time between major updates of software now, plus the power available at the low end of the market, breaks this cycle.
The one place that this is somewhat not true is with the Microsoft Vista operating system, if you want to run it with all the bells and whistles. If you want that then the low end machines might not be exactly what you want. If you are only wanting to surf the web and do e-mail you should consider alternative operating systems that run on the same hardware, such as a Linux distribution like Ubuntu.
The Macintosh computers are more expensive, but come loaded with a lot more bells and whistles that narrow the gap between the low end PC and the low end Mac. They offer a good level of stability and if you are looking for easy they are hard to beat.
When you go to purchase your next computer, consider all the factors, including what you are actually SPECIFICALLY going to use the machine for, and do not fall for the sales pitch of the latest, greatest and fastest. A "good enough" computer is going to be sufficient for 95% of people, so don't turn up your nose at a computer because of its low price. You'll be pleasantly surprised by your new machine, regardless.
Make your choice techgnostically, and don't be swayed by hype (I'm looking at YOU, Microsoft).
Tuesday, March 18, 2008
Object Relational Mapping
I saw a demonstration last night of object relational mapping (ORM) tools. The idea behind them is that object oriented programming (OOP) and relational databases (RDBMS) model the world in two totally different ways. OOP tries to express everything in terms of behavior and properties, whereas RDBMS focus on efficient data storage, and do not support the kind of behavior that OOP provides. You can program in a RDBMS (with stored procedures, or functions) and you can store data in objects. Both approaches have their pros and cons. At the moment, OOP is the dominant way to write software (Java and .NET languages sit on top of huge libraries of objects) and RDBMS is the dominant way to store data (Oracle, SQL Server, etc.).
Programmers being programmers, clever people have put together some ways to allow the OOP people to have their cake and eat it too. They can program against objects, and then have a whole bunch of backend code handle the dirty details of getting data out of and back into the RDBMS. Of course, there is no such thing as a free lunch, so there is an overhead associated with this.
I could see how the approach would allow you to cleanly separate out your business objects (e.g., customers, orders, etc.) from the nitty gritty of the data storage (e.g., the exact SQL statements to retrieve or insert data into a database) and insulate your business logic from future changes in data storage technology. Some frameworks go one step further and define a domain specific language (DSL) to allow you to express your business problem solution in something that resembles normal English (COBOL-esque?).
In a large number of cases, there is significant investment in existing code, written in such a way that you cannot simply switch approaches on a whim. When something like ORM comes along there needs to be a cost-benefit analysis (CBA) of whether or not it is worth it to make the switch. The software developers hear this and hear "blah blah blah", knowing that the suits just want to kill their fun. If they are serious enough about their fun they will go to a startup company that is doing greenfield development where they can indulge their latest cutting edge ideas.
Ironically, in three to five years something else will come along, and if they have totally bought into whatever the new thing NOW is (for example, ORM) they will decry any attempt to move away from it, having written tens of thousands of lines of code using it.
I guess it is the fate of all software development to eventually become obsolete and fall by the wayside, but in some niches you can survive for a very long time until that CBA finally tips the scales over, and the maintenance payments to whichever vendor or ability to find programming talent to keep your AS400 / COBOL / PowerBuilder payroll system alive become too difficult.
I suspect I will run a small pilot project using an ORM framework, to see what benefit there is, and to show that we are "keeping up", but for now I think it is going to be one of those things that simply does not pay off enough to warrant a wholesale shift.
Programmers being programmers, clever people have put together some ways to allow the OOP people to have their cake and eat it too. They can program against objects, and then have a whole bunch of backend code handle the dirty details of getting data out of and back into the RDBMS. Of course, there is no such thing as a free lunch, so there is an overhead associated with this.
I could see how the approach would allow you to cleanly separate out your business objects (e.g., customers, orders, etc.) from the nitty gritty of the data storage (e.g., the exact SQL statements to retrieve or insert data into a database) and insulate your business logic from future changes in data storage technology. Some frameworks go one step further and define a domain specific language (DSL) to allow you to express your business problem solution in something that resembles normal English (COBOL-esque?).
In a large number of cases, there is significant investment in existing code, written in such a way that you cannot simply switch approaches on a whim. When something like ORM comes along there needs to be a cost-benefit analysis (CBA) of whether or not it is worth it to make the switch. The software developers hear this and hear "blah blah blah", knowing that the suits just want to kill their fun. If they are serious enough about their fun they will go to a startup company that is doing greenfield development where they can indulge their latest cutting edge ideas.
Ironically, in three to five years something else will come along, and if they have totally bought into whatever the new thing NOW is (for example, ORM) they will decry any attempt to move away from it, having written tens of thousands of lines of code using it.
I guess it is the fate of all software development to eventually become obsolete and fall by the wayside, but in some niches you can survive for a very long time until that CBA finally tips the scales over, and the maintenance payments to whichever vendor or ability to find programming talent to keep your AS400 / COBOL / PowerBuilder payroll system alive become too difficult.
I suspect I will run a small pilot project using an ORM framework, to see what benefit there is, and to show that we are "keeping up", but for now I think it is going to be one of those things that simply does not pay off enough to warrant a wholesale shift.
Subscribe to:
Posts (Atom)