When I got home last night, the latest issue of eWeek had arrived and my wife had left it on the kitchen table for me. Call me old fashioned if you will, but I've been a subscriber to the dead-trees edition of several magazines ever since I got my first professional subscription - to WebWeek back when I was a full-time webmaster. The online versions just don't cut it for me. I stare at a computer monitor for far too long each day and my eyes like looking at paper.
One of the stories on the cover is Dealing with Mac Creep. I did not get a chance to read it yet, and I will not be reading the online version that I just linked to so it'll have to wait until this evening. But that article title was enough to get me to thinking.
And before I go any further, I have to make a confession: I like Macs. Sure, I work at a Windows software company, my first computer experience was on a TRS-80, and most of my time spent working is on Windows. But I've always had a bit of an interest in Macs from a networking standpoint, I married a Mac woman (she has a marketing and design background, what do you expect?) and when OS X first came out, I was very excited by the BSD underpinnings because I had done so much with Linux and FreeBSD. At home, we have a PC and an iMac. The kids and my wife use the iMac while I have always used the PC. But these days, the PC is basically just a VM host for a file server virtual machine. When I work from the iMac and I need to compile some code under Windows, I just use remote desktop, either to my home PC or to my office PC.
I think Macs are a natural for general business use. Linux will continue to struggle on the desktop because it is hard to get working and the applications available are limited. Macs though are just plain easy to use and work well. (Of course, it's easier for Apple to deliver that experience since they control both the OS and the hardware.) And while Macs may not have the same depth in its software library as Windows, there is still quite a bit in it and I see more and more applications moving to the web anyway. OK, the users themselves are well covered.
Now tack on what appealed to my inner geek originally, the BSD core, and IT should be happy. They may not be familiar with it, but they should at least have enough of an interest in technology to understand the implications. And if they are afraid to learn, they should be looking for a new career anyway.
That leaves only our friends with the black and red pens. When the finance folks first see an iMac starts at $1099 compared to around $400-500 for a commodity PC, they aren't going to be too happy. But assuming you roll out a new machine every 3 years, an extra $200/year towards employee morale is a good investment in my mind.
I wonder if I'll have a Mac on my desktop at work any time soon.
Thursday, April 24, 2008
Thursday, April 17, 2008
Is Anyone Really Surprised by Sun?
News from the MySQL Conference indicates that Sun will be adding some new features only to MySQL Enterprise, and not the more common (and open-source) MySQL Community. Is anyone really surprised by this?
Google does it with Google Apps vs. GMail. Sun is already doing this with StarOffice vs. OpenOffice. Red Hat has been doing it for quite some time now with Red Hat Enterprise Linux vs. Fedora. InnoBase, now owned by Oracle, does it with InnoDB HotBackup vs. InnoDB. There are countless other examples out there too.
And the reasoning is pretty simple - at the end of the day, we all need to get paid. Even within the open source community, people have bills. We might all like to be idealists and work on a project just because we enjoy it, but that isn't going to put clothes on your back or keep your house warm during the winter. You still need to find a way to make some money.
Google, Sun, Red Hat and Oracle need to make money too. The way to do that is by actually charging for what they do instead of giving it all away. If the free product is "good enough" for your situation, you are in luck. But if you are after more advanced features, then you probably have a real business need for the product and should understand having to pay for it.
It's much like transportation. You can get anywhere you want for free by walking or swimming. But if you need or want to get to your destination faster, easier or maybe with more luggage, then you are going to need to pay in some fashion to take a car, bus, train, plane or boat.
Sun's move should not be unexpected to anyone. It doesn't mean they are evil, it just means they live in the real world.
Google does it with Google Apps vs. GMail. Sun is already doing this with StarOffice vs. OpenOffice. Red Hat has been doing it for quite some time now with Red Hat Enterprise Linux vs. Fedora. InnoBase, now owned by Oracle, does it with InnoDB HotBackup vs. InnoDB. There are countless other examples out there too.
And the reasoning is pretty simple - at the end of the day, we all need to get paid. Even within the open source community, people have bills. We might all like to be idealists and work on a project just because we enjoy it, but that isn't going to put clothes on your back or keep your house warm during the winter. You still need to find a way to make some money.
Google, Sun, Red Hat and Oracle need to make money too. The way to do that is by actually charging for what they do instead of giving it all away. If the free product is "good enough" for your situation, you are in luck. But if you are after more advanced features, then you probably have a real business need for the product and should understand having to pay for it.
It's much like transportation. You can get anywhere you want for free by walking or swimming. But if you need or want to get to your destination faster, easier or maybe with more luggage, then you are going to need to pay in some fashion to take a car, bus, train, plane or boat.
Sun's move should not be unexpected to anyone. It doesn't mean they are evil, it just means they live in the real world.
Thursday, April 10, 2008
Web Security Good Enough for Google
Web applications are gaining tremendous momentum, due in no small part to the fact that they can be available everywhere and to everyone. But that is a double-edged sword, since not everyone with an Internet connection is a "good guy".
Make no mistake: If you put an application on the Internet, someone will find it and try to break into it. If you think otherwise, you are only fooling yourself and putting your data at risk.
Google recently shared some of its security secrets at RSA Conference, which focuses on information security. The article is a bit scant on details and I'm hoping that more information about Scott Petry's session will become available, but what is there is still very valuable. Google's Vice President of Engineering, Douglas Merrill, also shared some security insight back in June of 2007.
There are two recurring themes in both of these articles, and I could not agree more strongly with them. First, security is something that the developer must have real knowledge about. Second, security is something that must be considered from the beginning and not tacked on at the end.
Learn about web security, and make sure you understand it. If you are developing web applications, you need to know this stuff.
And don't hesitate to use the tools available to help you secure your application. The Security Framework in Alpha's Application Server is a giant leap forward and can get you well on your way. Just remember to consider all potential attack vectors and address them.
Make no mistake: If you put an application on the Internet, someone will find it and try to break into it. If you think otherwise, you are only fooling yourself and putting your data at risk.
Google recently shared some of its security secrets at RSA Conference, which focuses on information security. The article is a bit scant on details and I'm hoping that more information about Scott Petry's session will become available, but what is there is still very valuable. Google's Vice President of Engineering, Douglas Merrill, also shared some security insight back in June of 2007.
There are two recurring themes in both of these articles, and I could not agree more strongly with them. First, security is something that the developer must have real knowledge about. Second, security is something that must be considered from the beginning and not tacked on at the end.
Learn about web security, and make sure you understand it. If you are developing web applications, you need to know this stuff.
And don't hesitate to use the tools available to help you secure your application. The Security Framework in Alpha's Application Server is a giant leap forward and can get you well on your way. Just remember to consider all potential attack vectors and address them.
Monday, April 07, 2008
Expensive Pizza
Pizza is usually a pretty simple food, but there are all sorts of gourmet variants too. I've had some expensive stuff in my day, and I've even enjoyed some of it. But this tops them all: pizza.com was sold for $2.6 million on Friday by domain auctioneer sedo.com. Not bad for a $20/year investment by some guy that had bought it in 1994 hoping to land a consulting gig.
It makes pizza.info a steal at the current bid of 12,500 EUR.
Kinda makes me wish I hadn't let a few domain names expire in years past. Maybe I should flip through the unused domain names I have left. I'm not a greedy guy so I'd be happy to let them all go as a package deal for the rock-bottom price of only $1.5 million. Any takers?
It makes pizza.info a steal at the current bid of 12,500 EUR.
Kinda makes me wish I hadn't let a few domain names expire in years past. Maybe I should flip through the unused domain names I have left. I'm not a greedy guy so I'd be happy to let them all go as a package deal for the rock-bottom price of only $1.5 million. Any takers?
Thursday, April 03, 2008
Fungible, My Ass!
1 != 1 (that's "one does not equal one" for all you non-geeks) when you're talking about people. Sure, it holds true for bits of data, produce, and gold. People are different.
Martin Heller agreed with Richard Rabins when he said "Software developers are not fungible commodities to be bought and sold." That led to a post on Martin's InfoWorld blog, Strategic Developer, a couple of weeks ago. At the time, I was pleased to see Alpha Software mentioned on the InfoWorld site, but I was also a bit surprised by the content of Martin's mention. Doesn't everyone already know developers are not a commodity, let alone a fungible one?
Apparently not! After two weeks, Martin got such varied responses to his agreement with Richard's assertion that he's made a second post just to summarize the discussion.
I have to admit that I am not overly surprised by the disagreement and wide range of opinions even though I think it is pretty much common sense that while you can substitute one bushel of corn for another, you cannot substitute one worker for another. And notice I said "worker", not developer. Sure, I work in technology and the developer is more directly visible to my colleagues, peers, and me, but it is just as true when applied to ditch diggers.
The counter argument that tries to say workers are fungible usually goes something like, "It's just a matter of training and education." You just can't teach certain things though - work ethic, aptitude, natural talent, etc.
Next time you drive by a road crew "working", notice the 1 or 2 people doing the actual work while many more look on. Sure, I'm stereotyping here, but stereotypes come from reality. Chances are that those 1 or 2 doing the work have a better work ethic than the others. Yeah, they could just be the new guys that get dumped on, I'm sure that happens too. But I personally know several people that work in similar environments yet consistently work reliably while others look on or otherwise waste time - not because someone is cracking a whip or hazing them, but because they feel that it is their duty to do so. You just can't teach that.
Now go to your local auto mechanic, car dealership or oil change chain and walk into the repair bay, or peer in closely while standing next to the ominous "insurance regulations do not permit..." sign. If there is more than one mechanic working, I bet you'll see some differences in the way they get work done. Sometimes it's just a matter of work ethic, but I know even from my very early work experience that it is often something more. My father owns a gas station and auto repair shop (with a woefully out of date web site) and I worked there through junior high and high school. While there, I observed my brothers as well as other employees and how they worked. Even within my own family that shared a similar work ethic, there were distinct differences. One of my brothers just was not as good despite his best efforts. He wasn't doing anything wrong, he wasn't lazy, and he wasn't stupid. But his hands just didn't hold the tools as comfortably and his mind didn't visualize the problem as well. We all got the same "training" growing up working on cars, but you just can't learn what he didn't have.
In some cases, persistence can make up for skill and vice versa. The ditch digger that holds his shovel awkwardly can work faster in an attempt to move as much dirt as someone else, while the lazy digger that has outstanding technique can still move plenty of dirt too. Yet neither of these folks will accomplish as much as a skilled, motivated and natural person. And let's not forget that the awkward person is going to tire and slow down or even burn out completely and the lazy person is going to impact everyone else's morale.
In the world of programming, these differences often have more insidious effects. If your work crew has a lousy ditch digger, you'll probably know it at the end of the day when you see his work compared to the rest. But a programmer that's not up to snuff may very well write some code that appears to function well and do it in a timely manner. For now...
Let me make it clear that I'm not talking about just a bug here. We've all mistyped something, worked a bit too late in an effort to get just a little more done for the day, created a routine that was off by 1, or generally made some other kind of "silly" mistake. These "simple" bugs can be dangerous too, but they will not run rampant and consume your code like that guy that you hired just because he seemed like he'd work for a bit less than the other candidates.
Does he stink at building algorithms because his mind simply doesn't work that way so he ends up introducing what functionally amounts to a back door with the potential for a massive Hanaford-scale data breach? Or maybe his weakness is in conceptualizing threading and now your application is full of race conditions. Perhaps his specialty is uninitialized variables that lead to unpredictable behavior even though he's been taught repeatedly to always initialize them, but he just doesn't see the need to do so.
There's an easy solution here though. Find, hire and retain the best people that you can. And when the occasional lousy one slips through the cracks and gets a job working for you, don't hesitate to get rid of him.
Martin Heller agreed with Richard Rabins when he said "Software developers are not fungible commodities to be bought and sold." That led to a post on Martin's InfoWorld blog, Strategic Developer, a couple of weeks ago. At the time, I was pleased to see Alpha Software mentioned on the InfoWorld site, but I was also a bit surprised by the content of Martin's mention. Doesn't everyone already know developers are not a commodity, let alone a fungible one?
Apparently not! After two weeks, Martin got such varied responses to his agreement with Richard's assertion that he's made a second post just to summarize the discussion.
I have to admit that I am not overly surprised by the disagreement and wide range of opinions even though I think it is pretty much common sense that while you can substitute one bushel of corn for another, you cannot substitute one worker for another. And notice I said "worker", not developer. Sure, I work in technology and the developer is more directly visible to my colleagues, peers, and me, but it is just as true when applied to ditch diggers.
The counter argument that tries to say workers are fungible usually goes something like, "It's just a matter of training and education." You just can't teach certain things though - work ethic, aptitude, natural talent, etc.
Next time you drive by a road crew "working", notice the 1 or 2 people doing the actual work while many more look on. Sure, I'm stereotyping here, but stereotypes come from reality. Chances are that those 1 or 2 doing the work have a better work ethic than the others. Yeah, they could just be the new guys that get dumped on, I'm sure that happens too. But I personally know several people that work in similar environments yet consistently work reliably while others look on or otherwise waste time - not because someone is cracking a whip or hazing them, but because they feel that it is their duty to do so. You just can't teach that.
Now go to your local auto mechanic, car dealership or oil change chain and walk into the repair bay, or peer in closely while standing next to the ominous "insurance regulations do not permit..." sign. If there is more than one mechanic working, I bet you'll see some differences in the way they get work done. Sometimes it's just a matter of work ethic, but I know even from my very early work experience that it is often something more. My father owns a gas station and auto repair shop (with a woefully out of date web site) and I worked there through junior high and high school. While there, I observed my brothers as well as other employees and how they worked. Even within my own family that shared a similar work ethic, there were distinct differences. One of my brothers just was not as good despite his best efforts. He wasn't doing anything wrong, he wasn't lazy, and he wasn't stupid. But his hands just didn't hold the tools as comfortably and his mind didn't visualize the problem as well. We all got the same "training" growing up working on cars, but you just can't learn what he didn't have.
In some cases, persistence can make up for skill and vice versa. The ditch digger that holds his shovel awkwardly can work faster in an attempt to move as much dirt as someone else, while the lazy digger that has outstanding technique can still move plenty of dirt too. Yet neither of these folks will accomplish as much as a skilled, motivated and natural person. And let's not forget that the awkward person is going to tire and slow down or even burn out completely and the lazy person is going to impact everyone else's morale.
In the world of programming, these differences often have more insidious effects. If your work crew has a lousy ditch digger, you'll probably know it at the end of the day when you see his work compared to the rest. But a programmer that's not up to snuff may very well write some code that appears to function well and do it in a timely manner. For now...
Let me make it clear that I'm not talking about just a bug here. We've all mistyped something, worked a bit too late in an effort to get just a little more done for the day, created a routine that was off by 1, or generally made some other kind of "silly" mistake. These "simple" bugs can be dangerous too, but they will not run rampant and consume your code like that guy that you hired just because he seemed like he'd work for a bit less than the other candidates.
Does he stink at building algorithms because his mind simply doesn't work that way so he ends up introducing what functionally amounts to a back door with the potential for a massive Hanaford-scale data breach? Or maybe his weakness is in conceptualizing threading and now your application is full of race conditions. Perhaps his specialty is uninitialized variables that lead to unpredictable behavior even though he's been taught repeatedly to always initialize them, but he just doesn't see the need to do so.
There's an easy solution here though. Find, hire and retain the best people that you can. And when the occasional lousy one slips through the cracks and gets a job working for you, don't hesitate to get rid of him.
Subscribe to:
Posts (Atom)
