I was talking with my young niece a few days ago about getting shots. She told me she really hated them. I then told her a story about my brother who had always had a deathly fear of shots. At one point he and I were talking about this (as children), and it came up that he had always thought that when the doctor pushed the plunger in, it was making the needle go further into his arm. He said he was really frightened that it would go into his bone.
At that point my niece's eyes got big and she said, "You mean, it doesn't push the needle further in?"
I was intrigued that she had the same mis-information as my brother. It made me think of how hard I work to give correct information in order to set expectations. I feel that one characteristic of good engineering is to set expectations correctly. This may sometimes go against the wishes and hopes of the marketing and sales folks, but it has to be done. I do, however, feel that (in the long run) setting expectations correctly works for both me as a producer of software and my customers as consumers of software. By "customer" here I mean both internal (e.g., within the company) and external (e.g., paying) customers.
If I set expectations too high and don't meet them, my credibility is damaged, and people have a long memory for failure.
Sunday, November 25, 2007
Monday, November 19, 2007
Lowest Common Denominator Wins This One
Today I came across this article from Component Developer Magazine about ODBC. I was especially amused (and bemused) by this quote:
At the time of its release, the SQL Server team at Microsoft believed OLE DB would supersede ODBC. This is not longer the case and ODBC's future is completely secure. ODBC is more widely used that OLE DB and it is better suited to some key scenarios that I will discuss later in this article.
I was originally planning to title this post "Old APIs Never Die, And They Never Fade Away Either." The message here, though, seems to indicate (if by omission only) that OLE DB's future is not completely secure. Or maybe I'm just trying to dig too far into the sub-text.
In any case, I believe this is a case where ODBC (as clumsy as some think it is) has won precisely because it is low level, focused on one task, and does not have a lot of proprietary technology that needs to be duplicated across platforms. While ODBC on non-Windows platforms such as Solaris and Linux still has a lot of rough edges, it's generally usable except for the occasional configuration nightmare.
I wonder, on the other hand, what will happen with efforts such as Mono, which are attempting to duplicate a much higher level of functionality and more compilicated interface. As Wikipedia says (today, anyway):
The Microsoft compatibility stack provides a pathway for porting Windows .NET applications to Linux. This group of components include ADO.NET, ASP.NET, and Windows.Forms, among others. As these components are not covered by ECMA standards, some of them remain subject to patent fears and concerns.
Sometimes one's eyes are bigger than one's stomach.
At the time of its release, the SQL Server team at Microsoft believed OLE DB would supersede ODBC. This is not longer the case and ODBC's future is completely secure. ODBC is more widely used that OLE DB and it is better suited to some key scenarios that I will discuss later in this article.
I was originally planning to title this post "Old APIs Never Die, And They Never Fade Away Either." The message here, though, seems to indicate (if by omission only) that OLE DB's future is not completely secure. Or maybe I'm just trying to dig too far into the sub-text.
In any case, I believe this is a case where ODBC (as clumsy as some think it is) has won precisely because it is low level, focused on one task, and does not have a lot of proprietary technology that needs to be duplicated across platforms. While ODBC on non-Windows platforms such as Solaris and Linux still has a lot of rough edges, it's generally usable except for the occasional configuration nightmare.
I wonder, on the other hand, what will happen with efforts such as Mono, which are attempting to duplicate a much higher level of functionality and more compilicated interface. As Wikipedia says (today, anyway):
The Microsoft compatibility stack provides a pathway for porting Windows .NET applications to Linux. This group of components include ADO.NET, ASP.NET, and Windows.Forms, among others. As these components are not covered by ECMA standards, some of them remain subject to patent fears and concerns.
Sometimes one's eyes are bigger than one's stomach.
Saturday, November 17, 2007
Share the Wealth
When I was leaving one of my previous jobs, I was working with a younger developer who was going to take over some of my responsibilities. While I had been working there I had written documents describing procedures and processes that I had put in place for myself. I had been keeping these documents (as well as some code for personal regression tests) in a source code repository using CVS. The repository was on the laptop machine with the working copy on the desktop machine. I used CVS because the company source code system (ClearCase) wasn't set up to allow personal archives. I also prefer not to use ClearCase when possible, but I'll save that rant for another post.
The day I left I cleaned out the CVS directories in my local copy of the directory tree, zipped it up and emailed that zip file to him. I didn't want to give him the CVS repository itself because I didn't want to confuse him any more than necessary.
I also changed the password on my email (Lotus Notes) and made sure that all my emails had been put into my local email database. I then gave him a copy of that database along with the password and made sure that he could open that local database on his machine. He looked at me, slightly puzzled, and asked if there weren't emails that I didn't want him to see. I told him that I knew from the day I started that these emails were really property of the company and they didn't belong to me. I never, therefore, used it for any personal purposes or sent any emails that I wouldn't want "read out loud in the town square" (to quote my brother-in-law).
I don't know if he ever actually looked at any of this, or whether he considered it wealth or dross. I did, however, feel better leaving the information with him, rather than letting it be wiped when my work machines were returned to the company pool.
The day I left I cleaned out the CVS directories in my local copy of the directory tree, zipped it up and emailed that zip file to him. I didn't want to give him the CVS repository itself because I didn't want to confuse him any more than necessary.
I also changed the password on my email (Lotus Notes) and made sure that all my emails had been put into my local email database. I then gave him a copy of that database along with the password and made sure that he could open that local database on his machine. He looked at me, slightly puzzled, and asked if there weren't emails that I didn't want him to see. I told him that I knew from the day I started that these emails were really property of the company and they didn't belong to me. I never, therefore, used it for any personal purposes or sent any emails that I wouldn't want "read out loud in the town square" (to quote my brother-in-law).
I don't know if he ever actually looked at any of this, or whether he considered it wealth or dross. I did, however, feel better leaving the information with him, rather than letting it be wiped when my work machines were returned to the company pool.
Sunday, November 11, 2007
The "Dead Leaves" Guy
My family and I have lived in the same house for the past 24 years. Once or twice a year I squeeze myself between our "Florida Room" and the neighbor's garage to clean out the oak leaves that end up there. It's a tight fit, and not a task I enjoy. When it's done, I step back, dust off my hands (figuratively and literally) and take the green waste bin out to the street for pickup.
I've always gotten along well with our next door neighbors, who have been there for more than a decade. Last weekend I noticed the husband up the roof of his garage, merrily sweeping the oak leaves into the space that I have been squeezing into all these years. He looked a little sheepish, but said he had been doing this all along. I told him that if I hadn't been cleaning them out, we would have had oak trees trying to grow between our buildings. I then assured him that it was OK with me, and we went to our various tasks.
I have also been cleaning out a lot of "dead leaves" that others have put into our code at work. I am concerned when I see code that is so obviously cut-and-pasted instead of refactored. I sometimes wonder what people think when they are doing this. Are they concerned because they don't understand the code well enough to do refactoring? Are they too overloaded to think about the fact that what they put in may sprout into oak trees in the worst possible place? Are they too rushed to think a few months down the road, or a year or two?
It concerns and mystifies me.
I've always gotten along well with our next door neighbors, who have been there for more than a decade. Last weekend I noticed the husband up the roof of his garage, merrily sweeping the oak leaves into the space that I have been squeezing into all these years. He looked a little sheepish, but said he had been doing this all along. I told him that if I hadn't been cleaning them out, we would have had oak trees trying to grow between our buildings. I then assured him that it was OK with me, and we went to our various tasks.
I have also been cleaning out a lot of "dead leaves" that others have put into our code at work. I am concerned when I see code that is so obviously cut-and-pasted instead of refactored. I sometimes wonder what people think when they are doing this. Are they concerned because they don't understand the code well enough to do refactoring? Are they too overloaded to think about the fact that what they put in may sprout into oak trees in the worst possible place? Are they too rushed to think a few months down the road, or a year or two?
It concerns and mystifies me.
Wednesday, October 24, 2007
Glosses on Linus Torvalds Coding Style
A gloss is a marginal note (see picture in the Wikipedia entry for an example). While one can't very well annotate someone else's web page, I will add my voice to the chorus of those who have commented on Linus Torvalds coding style document.
I strongly agree with almost everything said in this document, and have been glad for the "backup" when I've had to argue a point with some of my fellow workers. There are, however, a couple of items where I diverge.
The first point that I would gently argue is that 8-space tabs are too deep. I haven't "been looking at [my] screen for 20 straight hours" for a couple of years, but at the very outset I worked with 4-space tabs, and I find them very readable. I haven't worked with anyone who has strongly defended 8-space tabs. I will admit that I have had to try to persuade people to switch from 2-space to 4-space tabs, but that was back in the Apple ][ Basic days when people were trying to keep their programs as small as possible (remember cassettes?). I don't know of any readability studies on this topic, and would be interested to see them.
My second argument (or shall I say "disagreement" to be less disagreeable...) is with his distaste for mixed-case names. I find mixed-case easier to read (maybe it's just me), but, more importantly, I find it a lot easier to type than underscores. I know I'm not the best touch-typist in the world, but I always find myself looking down to make sure that my ring-finger is indeed hitting the dash/underscore key and not one of its neighbors. Using camelCase keeps my fingers on the home row much more, makes my typing faster and reduces the number of errors.
These are just friendly disagreements, however, and don't diminish the fact that I'm glad this document exists, and is available to us all.
I strongly agree with almost everything said in this document, and have been glad for the "backup" when I've had to argue a point with some of my fellow workers. There are, however, a couple of items where I diverge.
The first point that I would gently argue is that 8-space tabs are too deep. I haven't "been looking at [my] screen for 20 straight hours" for a couple of years, but at the very outset I worked with 4-space tabs, and I find them very readable. I haven't worked with anyone who has strongly defended 8-space tabs. I will admit that I have had to try to persuade people to switch from 2-space to 4-space tabs, but that was back in the Apple ][ Basic days when people were trying to keep their programs as small as possible (remember cassettes?). I don't know of any readability studies on this topic, and would be interested to see them.
My second argument (or shall I say "disagreement" to be less disagreeable...) is with his distaste for mixed-case names. I find mixed-case easier to read (maybe it's just me), but, more importantly, I find it a lot easier to type than underscores. I know I'm not the best touch-typist in the world, but I always find myself looking down to make sure that my ring-finger is indeed hitting the dash/underscore key and not one of its neighbors. Using camelCase keeps my fingers on the home row much more, makes my typing faster and reduces the number of errors.
These are just friendly disagreements, however, and don't diminish the fact that I'm glad this document exists, and is available to us all.
Saturday, October 20, 2007
Pythonics Anonymous
I think I need a twelve-step program to wean myself from Python.
When I first looked at Python a few years ago I was put off by the fact that white space was significant. I also thought that having to do "self." to indicate object fields (vs. global variables or parameters) was just noise. I got tired, however, of always looking up Perl syntax, and I really didn't care for the Perl TMTOWTDI (I prefer one good way to do things, not many). I then came across Eric Raymond's article and decided to learn and use Python.
Now, after a few years of working with the language I appreciate the fact that white space is significant (no more bracket-placement wars!). I also appreciate the cross-platform-ability and the fact that (even though it is open-source) it isn't GPL, which has allowed us to use it at a company I used to work for. I like having the various supporting packages (although the minidom has a problem when pretty-printing XML that I had to work around).
However, I now find myself thinking that I'd better go back to Java. I was put off Java because the reality took a really long time to catch up with the hype. Remember "Write once, run anywhere?" (which was really "Write once, debug everywhere?") It also seemed too heavyweight to me. I liked being able to run the Python interpreter in command line mode and experiment without having to fire up an editor, create files, save them and run them. It was also satisfying to be able to be able to write a one-line "Hello World".
It seems now, however, that the world (at least the world of enterprise software) has decided that It's A Java World. I guess I better get back on board. I know I'll fall off the wagon occasionally, but it's time to put Python back in the corner and get back to business.
When I first looked at Python a few years ago I was put off by the fact that white space was significant. I also thought that having to do "self." to indicate object fields (vs. global variables or parameters) was just noise. I got tired, however, of always looking up Perl syntax, and I really didn't care for the Perl TMTOWTDI (I prefer one good way to do things, not many). I then came across Eric Raymond's article and decided to learn and use Python.
Now, after a few years of working with the language I appreciate the fact that white space is significant (no more bracket-placement wars!). I also appreciate the cross-platform-ability and the fact that (even though it is open-source) it isn't GPL, which has allowed us to use it at a company I used to work for. I like having the various supporting packages (although the minidom has a problem when pretty-printing XML that I had to work around).
However, I now find myself thinking that I'd better go back to Java. I was put off Java because the reality took a really long time to catch up with the hype. Remember "Write once, run anywhere?" (which was really "Write once, debug everywhere?") It also seemed too heavyweight to me. I liked being able to run the Python interpreter in command line mode and experiment without having to fire up an editor, create files, save them and run them. It was also satisfying to be able to be able to write a one-line "Hello World".
It seems now, however, that the world (at least the world of enterprise software) has decided that It's A Java World. I guess I better get back on board. I know I'll fall off the wagon occasionally, but it's time to put Python back in the corner and get back to business.
Tuesday, October 9, 2007
Data Always Goes In A Database, Right?
Not necessarily.
I have worked on a number of software products where data (usually metadata) is stored in text or binary files. The code opens the file, reads from the file and parses the text (if necessary) into the structures used internally by the code. Over the years, the question has been asked more than once: why don't you put this data into a database?
There are a number of reasons not to use a database. First, all the data needs to be in memory for performance, and there is no advantage to keeping parts of it out on the disk. Second, the data is usually not appropriate for being "table-ized." That is, the data is complex and tree-structured rather than row-structured. I know that one can always flatten data into multiple tables with the appropriate keys and joins, but parsers built with tools such as Yacc and Lex will always be faster than doing multiple database joins and reads.
A third reason is that upgrading the data in the database requires scripts to add or modify tables or columns (deletes not being done to reduce the potential for referential integrity problems). Parsers can recognize a version number and do an upgrade-on-read, which doesn't require another program to run to perform the upgrade.
Fourth, files are easier for end-users to handle. For example, if a user needs to send some of his data to tech support, it's much easier for him to package up one or more files, rather than having to run some database dump utility and send the dump file. There is also no issue with (once having that database dump) the possibility that tech support does not have the particular version of the database software that the user is running.
A fifth reason (for text files at least), is that in a pinch the file can be opened and edited in a text editor if there are problems with it. With a database you have to run the appropriate database client software, then tease out the table relationships to understand where changes need to be made.
When all you know how to use is a hammer, everything looks like a nail.
I have worked on a number of software products where data (usually metadata) is stored in text or binary files. The code opens the file, reads from the file and parses the text (if necessary) into the structures used internally by the code. Over the years, the question has been asked more than once: why don't you put this data into a database?
There are a number of reasons not to use a database. First, all the data needs to be in memory for performance, and there is no advantage to keeping parts of it out on the disk. Second, the data is usually not appropriate for being "table-ized." That is, the data is complex and tree-structured rather than row-structured. I know that one can always flatten data into multiple tables with the appropriate keys and joins, but parsers built with tools such as Yacc and Lex will always be faster than doing multiple database joins and reads.
A third reason is that upgrading the data in the database requires scripts to add or modify tables or columns (deletes not being done to reduce the potential for referential integrity problems). Parsers can recognize a version number and do an upgrade-on-read, which doesn't require another program to run to perform the upgrade.
Fourth, files are easier for end-users to handle. For example, if a user needs to send some of his data to tech support, it's much easier for him to package up one or more files, rather than having to run some database dump utility and send the dump file. There is also no issue with (once having that database dump) the possibility that tech support does not have the particular version of the database software that the user is running.
A fifth reason (for text files at least), is that in a pinch the file can be opened and edited in a text editor if there are problems with it. With a database you have to run the appropriate database client software, then tease out the table relationships to understand where changes need to be made.
When all you know how to use is a hammer, everything looks like a nail.
Subscribe to:
Posts (Atom)