Thursday, January 17, 2008
Good Engineering Practices
Here are a few things that I believe are common to good engineering practice. These are not necessarily the most important issues for engineering a product, but they are a good things to consider. More important, they can be applied in most (probably all) development situations.
Make solutions as general and flexible as possible
About 25 years ago, I consulted to one of Ray Kurzweil’s companies. Ray Kurzweil is a futurist and luminary in the computer industry. One of the things I remember him saying was that he was really good at pattern recognition and that all of the products he developed (at that time they included a reading machine for the blind, a music synthesizer and a speech recognition system) were all based on pattern recognition. I believe that Kurzweil’s approach to computing let him see many problems in the general terms of pattern recognition. His approaches are flexible enough that he was easily able to apply his expertise to a solution.
When I was starting my career in the software industry, I wanted to write an operating system. (A lot of us did in those days.) At some point, I took a job working on a compiler. One of the things my boss told me was that developing a system and developing a compiler were very similar. In the general sense, he was right. While there are differences, there are lots of similarities. Both parse commands. Both track information about their activities—systems control processes and hardware, compilers control code generation and optimization. Both process errors. And lots more.
If one were to look at a database system, there are also more similarities than differences to compilers and operating systems. Similarities would include things like language processing for the query language and differences would include things like more complex data storage algorithms.
If one were to look at a browser like Internet Explorer or Firefox, it’s possible to view the application in the same light. Browsers are very much like a compiler—it’s actually an interpreter. The languages being interpreted include HTML, JavaScript and CSS among others.
The point is that a good engineer develops the ability to see similarities across applications and to understand the flexibility of their solutions so they can apply those solutions to new problems and in new environments.
Generalization and flexibility are applicable in the non-engineering world too. Since my blog includes a section on cooking, I'll give an example here. About month ago, I made an oven barbecued brisket. I decided a few days ago that I could make the same recipe with salmon and teriyaki sauce. The similarities: season a hunk of meat/fish; slice it thinly; cover the meat/fish in sauce and finish cooking. The differences: the brisket cooks a few hours before getting sliced and the salmon is sliced before it cooks (because cooking makes it flake apart); the brisket gets a strongly flavored barbecue sauce and the fish gets a milder flavored sauce; the brisket cooks for 1 hour/pound and the fish cooks for about 25 minutes total. In terms of generality and flexibility, I would say that these recipes are essentially the same with a few differences.
Plan for the required efficiency of the application
How efficient does a piece of code have to be? I believe that depends on what it’s doing and how it’s being used.
Notice that I said “piece of code” and not program. That’s because some parts of a program may have to be more efficient than other parts. If a user is typing into a text field on a form, the code handling the interaction does not have to be any faster than the typist. On the other hand, if the user is editing a database record and saving it, the save operation should be fast enough that the user’s wait time is kept to a minimum.
When my father began programming in 1951, computers were very expensive relative to employees. The computers of the time were also not very powerful and had very little memory or mass storage (like disks). So it was important to write programs that were as small and fast as possible.
Over time, hardware became better and cheaper and employees became much more expensive than the computer systems they and their end users would utilize. So writing the most efficient programs became less important. There was also the notion that if a program was too slow that the next generation of hardware would solve the problem. That approach got the world past decades—with lots of notable failures when the next generation of hardware was not enough faster to make the software perform well. If you want a modern day example, think about whether your fancy new computer running Vista is really performing better than your old clunker running XP.
I think that one of the problems some programs face is that the software designers and developers don’t examine the question of efficiency closely enough…or at all…or perhaps come to the wrong conclusions. A few months ago, I spoke with a manager in a company that develops real-time applications (applications that have a time-critical aspect to them). He asked me how I would speed up a stubbornly slow piece of code. I told him that after looking at the algorithms and making sure that there weren’t unexpected code paths being followed, that in the old days we might rewrite some critical code in assembler (machine language) but that I did’t think anyone wrote in assembler any more. He laughed and said that they still did that sometimes and that they were about to do some rewriting.
Imagine a developer is building an application that examines transactions in a credit card database. There is an enormous amount of data being processed in that case. Now imagine that the code is optimized so that it is 10% faster. 10% over a million transactions is a significant of time and is very probably a worthwhile thing to do.
Imagine the user I mentioned above who is typing into the text field of a form. If the user doesn’t perceive any lack of responsiveness, then a 10% improvement in performance will not be noticed and won’t make any difference.
To summarize, I don’t believe there is a single answer to the question of how efficient an application needs to be.
I hope you find these thoughts interesting and worthwhile and that they give you something to consider as you develop engineer your solutions.
Sunday, January 13, 2008
Visual Creativity: My First Photosurrealistic Picture

I remember looking at a picture I took in 1977 of Toronto’s New City Hall with a sundial in the foreground (the picture on the left). I always liked that picture. I decided to scan the slide and bring the image into the digital age. As I looked at it though, I also remembered a Hubble picture that I had seen of the galaxy M51 (the picture on the right).I began to wonder what it would be like to have the galaxy in the sky. Perhaps it was the globe of the sundial. Perhaps it was the building rising to the sky. In any case, the bright center of the galaxy seemed to me to be a potential “sun” in the sky.
In the end, I decided to place the galaxy in the sky with the results you see here.I hope you enjoy the picture and the thought processes and I’ll be interested in your comments.
Sunday, January 6, 2008
Improv Cooking: Best Rice Ever…and More
My daughter was visiting and wanted Cornish hens for dinner. Since there’s no way I could tell her no, I thawed a couple of birds that were in the freezer. When we ate dinner, she told me that she couldn’t say it was the best rice she had ever eaten because she didn’t remember every rice dish she’d eaten, but it had to be in the top rung. These are the recipes for the dinner—the hens is integrated into the preparation of the rice so I can’t separate the preparation of the two. Incidentally, this also works just fine with whole chickens instead of Cornish hens.
This dinner serves 3 or 4 people.Glaze for the Hens
When I started making this recipe around 1970, I used an inexpensive tawny port (not nearly as sweet as ruby port) and undiluted orange juice concentrate. Since we don't usually have orange juice concentrate around any more, I just triple the amount of OJ.Combine 1 part tawny port with 3-4 parts orange juice.
Since about 1/2 cup of the glaze will be used for cooking the rice, I wanted about 1 1/2 cup total. That's about 1/3 cup of port and 1 1/3 cup of OJ.Rice
Ingredients:Rinse the rice and put it into a small pot. Add the water, oil and seasonings to the rice and bring to a boil. Cook uncovered, stirring frequently until the liquid is reduced to the level of the rice in the pot. Reduce the heat to low, cover and cook for about 20 minutes—until the rice is done.
Cornish Hens (or Chicken)
Preheat the oven to 400.Pour a little olive oil in your hand and rub the hens all over on both sides. Put the hens on a rack over a baking pan breast side up. Sprinkle seasonings over the hens (I usually use pepper, garlic powder, turmeric, ground cinnamon, ground coriander and cumin). Turn the hens over and season the back the same way. If you're so inclined, rub the seasonings into the skin. (If you find a way to do that without having the seasonings clump up and stick to your hands more than the bird, please let me know.) Leave the birds on the rack breast side down.
Take the rack out of the baking pan and put the rice into the baking pan. Spread it around but try to keep as much of the rice as possible under where the hens will be. Put the rack back in the pan. Put the hens and rice into the oven and turn the temperature down to 350.After cooking for about 20 minutes, take the baking pan out of the oven and pour some of the glaze over the birds. (If you're using the concentrate use a basting brush to apply the glaze.) After another 15-20 minutes, turn the hens over breast side up and make sure the seasonings are still on. Make sure the rice is mostly under the bird. Pour on some more glaze. Cook for 20 minutes more. Pour the rest of the glaze on the hen and cook until the hens are done.
Green Beans and Mushrooms
To finish dinner, we had green beans and mushrooms. Clean two or three mushrooms and slice them. Wash some fresh parsley (I use flat leaf not curly parsley) and cut it up. Sautee the mushrooms in a little olive oil and grind some pepper over them. Add the cut up parsley and cook a bit more.Wash the green beans and break the stem end off them. Microwave the beans for 60-90 seconds. Mix the green beans with the mushrooms and parsley and you’re done.
You’ve got dinner!
Wednesday, January 2, 2008
Engineering: "Innovation" as a Cover for Bad Ideas
Most people, myself included, tend to think that innovation will improve things. In computer engineering, that might mean you could do things more easily or do new things with your computer, or that you computer would run faster.
About 5 months ago, I bought a new computer. It came with Windows Vista installed on it. Based on everything I had read and heard, I was lukewarm about getting Vista. Initially, I was under whelmed with Vista, but didn't see anything really bad about it. Since that time, I have become less impressed with Vista the more I use it. In particular, the system utilities are a definite step down from their counterparts in XP and their "User Account Control" that is designed to protect the system is SO annoying that I eventually turned it off (the only choice other than incredibly annoying).
As I was installing software on my new system, I had problems with Microsoft Office 2000, specifically with Word. So I decided that I'd break down and buy a new version and bought Office 2007. After suffering with Office 2007 for more than 2 months, I went back to Office 2000.
Microsoft likes to say that people, like me, who think that they have really done a bad job on their new software are against innovation. I think that they are being fatuous and supercilious--although that's nothing new for Microsoft.
Let's look at the "innovations" in Vista. As near as I can tell, the biggest thing is a slightly slicker user interface with translucent window borders. For this, they had to take years and disrupt millions of users?!? A programmer I knew years ago said that whenever a new Unix system programmer was introduced to the system, he would rewrite the terminal driver. I have the feeling that Microsoft gave in to a bunch of programmers who said essentially that they could do a much better job than the guys who wrote XP if they could start from scratch. In my opinion, they failed. Let's look at some specifics.
Windows Explorer:
They tried to make Windows Explorer be smart about what kind of files are in the directory and display things that are appropriate for that kind of directory. Unfortunately, it seems to guess wrong most of the time.
In some kind of cruel joke, Microsoft decided to include a "Favorite Links" area above the "Folders." There does not seem to be a way to get rid of it, which would allow more "Folders" to be seen. Nor does there seem to be any way to change the "Favorite Links" that are displayed. My question is who's favorite links are they. Certainly not mine--except for "Documents." Congratulations Microsoft. You got one of six of my favorites.
Although there is an option to make a directory style apply to all folders and subfolders, it doesn't seem to work and Windows Explorer applies its settings in place of the ones I tell it to use.
I'm sure that a fair amount of time went into rewriting a basic facility that worked well in XP. If there were some innovative new features, I'm sure it would have been easier to add them to the existing code than to rebuild the utility from scratch.
Disk Defragmenter:
The defragmenter in XP would analyze a disk or partition and tell the user how much fragmentation there was. It also had a cute and somewhat useless display to show the user it was working. It also attempted to give the user a clue about how far along it was in the process. The defragmenter is Vista is much simpler. It tells the user nothing except that "performance can be improved by defragmenting the disk". I tried running the defragmenter. I let it run for more than 24 hours and it was still cranking away with no indication of how much more there was for it to do. I never did discover if the defragmenter was working on both of my disks or only worked on one at a time.
I'm sure that a fair amount of time went into rewriting this tool that worked well in XP. If there were some innovative new features, I'm sure it would have been easier to add them to the existing code than to rebuild the utility from scratch.
User Account Controls:
This is really a new feature and had some potential. Unfortunately, the developers make this so intrusive that it becomes tempting to shut it off (the only option). A large number of programs that I run on a regular basis cause the UAC to warn me that the program is dangerous and insist that I explicitly allow the program to run. That's great--once. I have not found any way to tell the program that a particular program is ok and it doesn't have to ask me every time I run it.
Power Options:
When I was setting my system up, I installed Avast!, the anti-virus software I use. Avast! has an option to run a scan at boot time. Running a virus scan on a system takes a long time. It seems that some design genius decided that the monitor shutdown features of the Power Options should be applied before Vista was fully up. So after about 20 minutes, the screen went blank. Unfortunately, they didn't include the code that caused the monitor to come on again if a key was pressed. It took a while to figure out that this is what was happening and I believe that shutting power down in the middle of my first attempted scan damaged the system--which I think led to Word 2000 not working correctly. When I figured out what was happening, I restored Vista and started installing my software on a clean system.
Windows Mail:
Since Outlook 2000 won't work in Vista, I was forced into using Windows Mail. This is a poor substitute for Outlook Express found in XP.
Initiating a new mail message takes about 15 seconds. If I turn off automatic address completion, the message window is immediately available for use, but that's a major loss. XP was much faster in this regard.
I use more than one email address. The new Windows Mail program only allows one to send a new message from the default email address. In Outlook Express XP, I could choose the address the mail was sent from.
If these are innovations, they seem like bad innovations.
There's more I could write about Vista and its utilities, but I want to move on to Office 2007.
Office 2007:
As I mentioned in my comments on "Power Options," I decided to try to solve my problems with Word by buying a new copy of Office. I bought Office Home and Student 2007. The Vista problems didn't go away until I reinstalled Vista, but I had already opened the package so decided to keep it.
The "ribbon":
Since most laptop computers are now wide screen and the ribbon takes up a fair amount of vertical space across the top of the window (reducing the available space for the document in the more limited dimension), I started looking for a way to move it to the side (where there is a lot of unused space). I discovered that the ribbon could not be moved.
I tend to operate my computer from the keyboard as much as possible. I had shoulder problems a number of years that were exacerbated by using the mouse a lot. I also find using the keyboard faster and surer than using the mouse. The ribbon pretty much forces the user to use the mouse. If you happen to remember the entire keystroke sequence for a command in Office 2003, you can use the keyboard; otherwise, you must use the mouse.
I spoke with someone who works at Microsoft who told me that after about 6 weeks people decide they really like the ribbon. After fighting with it for about 10 weeks, I went back to Office 2000. Unfortunately, Outlook doesn't work under Vista so I was forced to use Vista's poor quality Mail and Calendar programs.
I tend to think of innovations as providing more, not fewer, options for users and making things better not worse.
The next thing I noticed was that the title bar on all of the windows stated something to the effect of Not for Commercial Use. My first reaction was that was really chintzy! My second reaction was that if Microsoft was going to put that on the software, they should warn users before they purchased the product that would be the case.
If you are ever tempted to defend an idea that people don't like, be careful about claiming the detractors are opposed to innovation. You might find yourself laughed at.
Wednesday, December 19, 2007
Engineering: Hiring Practices Then and Now
During my early years in the computer software industry, I worked in a number of jobs in both the US and abroad. Some of the groups I worked in were more successful than others. So when I was put in a position to build a software group of my own, I had already formed opinions about what made engineering groups successful. Since that first time I built a software group, I have had hire/fire/review responsibilities in a number of jobs in computer companies. I also ran a small computer software business for 14 years and occasionally hired help.
The two things that I looked for when hiring employees were:
- Intelligent people who could learn new things as required.
- People who fit well with the rest of the group.
- Intelligent people who had experience in the area they were going to work in.
- People who fit well with the rest of the group.
Hiring Intelligent People
You'll note that the only difference in my hiring was that for an employee, who would presumably be with me for years, I was willing to let the person spend a few weeks learning the particular skills necessary to do the job whereas for a consultant, who would presumably be with me for a short time, I didn't want to pay for the learning curve.
I am a strong believer that having the ability to learn quickly is much more important than knowing a particular programming language, development environment or application area. Each of those things will change over time so the ability to learn quickly is vital in the software business. But there's also a funny thing about new technologies that come along. They almost always have a lot of similarities with earlier technologies. I believe that is because good engineering principles tend to be rediscovered and reproduced in new environments. So if someone understands engineering, they will usually be able to learn new technologies quickly.
People Who Fit with the Rest of the Group
I once worked for a manager who rarely spoke with candidates about technical topics for more than a few minutes. The exception was if he was concerned about their abilities. After he got a sense of their technical savvy, he talked to them about other things. There was one person he hired who was from Oregon. The hiring manager had never been to Oregon but thought it sounded like an interesting place. He talked with someone else about cheese. This manager had the most productive section I have ever worked in. His groups were very cohesive, had low turnover, high productivity and high product quality.
Cohesive groups have lots of benefits for success and productivity. Cohesive groups are made up of people who: work well together; want to stay together because they enjoy working together and enjoy their mutual success; and, are comfortable admitting that they don't know everything and show it by asking colleagues for help or advice. As a manager, I was always very reluctant to bring someone into the group, even a short-term consultant, who could disrupt group cohesion.
I always told groups I managed that, barring a very unusual circumstance, at least one other person from the group would interview every candidate. In the years that I was a hiring manager, I never encountered a situation in which at least one other person from the group did not interview a candidate.
Hiring Then Conclusion
I don't think my hiring practices were that unusual in "the old days" when it was assumed that a person would quickly learn what they needed to know and that the ability to learn was generally more important that possessing a particular skill.
That seems to have changed today and I'll discuss that in the next section of this article "Hiring Now." Since I believe that hiring practices have gone seriously awry, I'll finish the article in the final part "What I Believe Is Really Happening."
In the mid-90s, I was looking for a senior software architect/lead developer for a group I had just taken over. I spoke with a recruiter from an outside agency and told him that I wanted someone very senior. He said, "You mean someone with 5-7 years?" I answered, "No. Someone with 15-20 years of experience." He was surprised and told me that I was the first hiring manager he had spoken with who would consider someone that senior--by which he meant old.
About a year ago, I spoke with a recruiter who told me the company she was recruiting for was looking for someone who could "hit the ground running." I asked how long they had been looking for that person and she told me about 6 months. I asked her if they wanted this person to stay with the company for a number of years and she said yes. Then I asked if they might consider hiring someone with a good background who might take a few weeks to get up to speed and she repeated that they wanted someone who could "hit the ground running." It makes no sense to me that a company would take an extended period to look for someone when someone with a good background and a reasonable experience level could pick up the necessary skills in short order.
I have been unsuccessfully looking for work for a few years. During that time, I have done a variety of things. At one point, I was doing some recruiting of software people for a friend's recruiting company. I found a client company that was looking for a person to work in their field organization. Their job description had a laundry list of skills. I asked the recruiter which ones were the most important and she told me all of them. I asked if I might speak with the hiring manager to get a better feel for what was important to him in the people he was seeking and was told that I could not bother him. So I sent a batch of resumes of people who met most of their requirements to see what they would say. The feedback on one person was that they didn't have a Unix background. I said that their requirements said that either Windows or Unix would be ok. The response was that Unix was what was important. I asked again about what was more important in some other areas and was again told that everything was important--and that I still couldn't speak with the hiring manager. Eventually, I was able to speak with the hiring manager who told me what was important and what was not--which didn't match the job description I had been given. The internal recruiter was eliminating people based on a invalid position description. Moreover, she didn't understand the words in either the position description or the resumes she was looking at.
One of my sisters has been a software recruiter for 25 years. She sees more and more recruiters who either have no experience in the software industry or have some experience but don't understand what they read in a resume. I believe that the situation is worse than that though. A lot of companies are now screening resumes by having computer programs scan resumes for keywords. So if an applicant uses a different word for something, they are eliminated even if they have the skill box checked.
This is all going on when companies are claiming that they cannot find qualified engineers. I believe that there has become a fundamental error in mistaking skills for qualifications.
Hiring Now Conclusion
As I have indicated, I think that current hiring practices have gone seriously awry. I believe that is bad for companies, employees and the country. It saps companies of skilled and experienced employees. It damages people who are unable to find meaningful work. It also damages the country in many ways including making engineering an unattractive profession for people trying to pick a career path.
Of course I could be wrong, but I believe that the main problems faced by experienced engineers today are: employers mistaking skills for qualifications, companies driving down salaries and age discrimination.
Mistaking Skills for Qualifications
As a hiring manager, I looked for people who had good engineering backgrounds. If I was recruiting for mid- to senior level positions, I looked for experience in more than one technological environment and not necessarily the one we were working in.
It seems to me that hiring has become focused on a particular skill set rather than a solid background. It's kind of like telling a writer that he is not qualified to write because he used WordPerfect rather than Microsoft Word. A writer is a writer because he or she knows how to write, not because of the tool used to do the writing. Similarly, an engineer is qualified because he or she knows how to design and build something, not because of the tool used to do the building--which is only part of the job anyway.
Radio interviewers try to delicately ask out of work engineers with 10 or more years of experience whether their problem might that they're unqualified. I wonder if their radio station changed the kind of recording devices they used (say from tape recorders to CD recorders) if they would consider themselves or their production people to be unqualified. Technology changes, but the underlying skills to do the job don't. Learning new technologies is not that big a deal--especially if someone has already worked in a number of different technological environments.
Driving Down Salaries
A few years ago, I learned that venture firms in the Boston area were refusing to fund companies that did not send their software development offshore. I always wondered, when all of the intellectual capital was overseas, what made the company a Boston-based company. I understand that with the large number of offshore development failures that some venture firms have changed their position on funding start-ups.
Somehow the notion took hold that American software engineers were inferior to foreign software engineers--especially Indian engineers. As experience has shown over time, that is nonsense. The best engineers from overseas are as good as the best American engineers. But the fact of the matter is that most projects are worked on by a more average caliber of engineer-who are no better and may not be as good as an average American engineer. My understanding is that American engineers tend to have a broader background than their counterparts who come from low wage countries.
Age Discrimination
When I was recruiting, one of my colleagues said that "any Java developer who wanted to work could find work." I asked him whether that was really true or if what he really meant was that "any Java developer under 40 who wanted to work could find work." He thought for a minute and then said, "under 30."
During my job hunt, I have run into a few examples of blatant age discrimination. In one case, I was interviewing for a position as a team lead for a C++ development group. In the end, they told me that they wanted someone who would grow into that position rather than someone who had already been in that role. Another time a recruiter actually told me that they wanted someone younger. Of course, this is illegal, but it's neither practical nor desirable to do anything about it.
Sometimes there could be an assumption that a more senior person will be more expensive. But even when a candidate expresses willingness to work for the offered salary, there is often still no offer forthcoming.
I have a friend who won PC Magazine's Technical Excellence Award. His office has shelves and shelves of books on the latest hot button technologies--up to two years ago. He is one of the best engineers I know. He has not been able to find work for a number of years. Two years ago, he quit following the latest technology trends in detail. His comment is, "Nobody wants us. We're dinosaurs."
About a year ago, PBS news brought a number of middle aged, out of work engineers together. The interviewer posed the question about them going back to school because their qualifications were out of date. One of the people said that he had gotten a second master's degree (I believe from MIT) and was still unable to find work. The other engineers had similar stories.
Recently, I met a former software engineer who described himself as a "hard core programmer." He told me that when he turned 60, his department had a little party for him. Unfortunately, 3 months later he became the only member of his department to be laid off. He was unable to find another job and has left the computer business. Needless to say, his income is now a fraction of what it was.
There is a lot of hand-wringing going on about America not producing enough engineers. I can't imagine why someone would want to become an engineer in today's climate. In today's climate, when an engineer reaches a sufficiently senior position, there is a reasonable chance that he will eventually become unemployable.
Before there is any chance at all of making engineering a desirable field again, it is necessary for people to feel that there is a good career path and a good future in it.
There is a lot of talk about requiring people to work more years since we are all living longer. I always wonder when I hear that, "Work at what?" Given the way the world works now, there is no reason to believe that someone working as an engineer would be able to find meaningful work for either the extra work years or even the end of their normal working life.
This is a societal problem that I'm sure is replicated in other industries--both blue and white collar. Unfortunately, none of our political leaders of either party seems to be addressing the issue. This cannot be good for our country.
Visual Creativity: What It Means to Me
In 2004, a retired professional photographer friend looked at both my photography and digital art. He told me that he thought of me as a creative thinker, but never realized that I was so visually creative. I think I understand what he was saying.
My daughter and I joke about our demented thought processes. Our upstairs bathroom has an old tile floor with random patterns in it. One day, we went into the bathroom and discussed the images we saw in the random patterns on the floor. Some of the things I see in the floor are Andy Capp (comic strip character), Gidney (a moon man from the old Rocky & Bullwinkle cartoon), Ghandi and a monkey wearing a fez.
In this section of the blog, I plan to discuss what I see and how I create an image from it.
Sometimes I look for the juxtaposition of the great and the small (like seeing a galaxy merged with a young fern). Other times I look for a splash of color in an image that I turn sepia. Yet other times, there’s just an interesting or whimsical scene.
I hope you enjoy the art and the thought processes and I’ll be interested in your comments.
Monday, December 3, 2007
Cooking: Improvisational Cooking and Why It Is a "Singular Vision"
A few years ago, my daughter told me I should write a cookbook about improvisational cooking--the way I cook. Since I can't say "no" to my daughter, I actually began compiling cooking styles and "recipes." Recipes and improvisational cooking are what the food section of the blog will be about.
When I'm making something that I've never made before, sometimes I'll actually follow a recipe but more often than not, I'll find a few recipes to ignore. I find the common themes among the recipes and incorporate them into the dish.
When I'm making something I've made before, I'm even looser in following any "recipe."
When I am planning a meal and am in the store (grocery or farm stand), I'll often pick something up (like a lemon) and try to imagine, visualize actually, how the food would taste with it and without it. Based on that, the item will probably either find it's way into the dish--or not.
I've been asked how I could repeat a recipe and if I can't, why is this a good way to cook. The fact is, I pretty much can reproduce most things I make. One reason improvisational cooking is good for me is that it gives me a daily creative outlet.
I have one constraint in my cooking that most people don't. My wife and I keep a kosher kitchen. At the simplest level means not mixing meat and dairy products, not using any pork products and using only fish that had fins and scales (no shellfish, eels or catfish). I don't use fancy or expensive kitchen tools. So anything I can do in the kitchen, you should probably be able to do too.
I encourage you to try cooking improvisationally. It's fun. It's creative. You'll get interesting results that will win you raves from friends.
Happy dining!
Sunday, December 2, 2007
Cooking: Coq au Salsa
- Whole cut-up chicken
- Sliced medium onion
- 4-8 sliced or quartered mushrooms
- 4-8 garlic cloves thinly sliced or minced
- Juice of a lime or two
- Sliced or otherwise cut up red pepper
- 1/4 - 1/2 cup of your favorite tomato-based salsa
- 1/4 cup of tomato-less, corn-based salsa
If you want to make your own salsa, cut up some tomatoes, chili peppers, cilantro, onion and garlic and add some corn, vinegar and sugar. - Freshly ground pepper, paprika, ground coriander, cumin and turmeric
- Tequila (optional)
- Chicken bouillon (optional)
- 2-3 tsp. corn starch (optional)
You can either make this in the oven or on top of the stove. I usually make this kind of recipe on top of the stove because it's faster.
Pull the skin off the chicken except for the wings. If you like schmaltz, you can render the skin with onions. Schmaltz is really unhealthy and a tablespoon is really good in mashed potatoes and can also be used in the next step of browning the chicken and onions.
Heat a few tablespoons of either olive oil or schmaltz over a medium heat in a large frying pan that has a cover. Saute the onions for a few minutes then add the garlic. Brown the chicken pieces on both sides. When the chicken is browned, add the warmed tequila (15 seconds in the microwave will do it). (I like to flambe things but I don't suggest that anyone else play with fire. What I do is wait until the tequila has had time to get hot, tip the frying pan to the side and very carefully light the tequila with a match.) After the flame has gone out, if you lit it, add the rest of the ingredients except the mushrooms and a cup or two of water or chicken bouillon. Turn the heat down to low, cover the pot and cook the chicken until it's done-probably about 45-60 minutes. (If you cook the chicken covered in the oven at 350, it will probably take 60-90 minutes.)
When the chicken has been cooking for about 1/2 to 3/4 of the time, add the mushrooms, re-cover the pan and continue cooking.
I like to thicken the sauce. Mix 2-3 tsp of corn starch with some cold water and add the mixture to the chicken. If there's too much liquid, leave the cover off the pan and simmer it on top of the stove. The corn starch will thicken the sauce.
Never let it be said that I don't continue with a theme for a dinner. Make some rice optionally substituting some tequila and/or sherry (I like amontillado) for about 1/4 of the liquid. Add a tablespoon of oil and some ground pepper, turmeric, cumin and coriander to the water before cooking. After cooking the rice, add some of both the tomato-based and tomato-less corn salsa to the rice and stir it in.
You've got dinner!