It's So Easy Being Green
If only someone had told Kermit the Frog... This is a great new blog that delivers at least one new and EASY step you can take towards living a more sustainable lifestyle. Not preachy or judgmental in the least, just practical advice in digestible amounts.
If you like that and want more check these out:
http://treehugger.com/
http://www.green-solutions.com/
http://www.coopamerica.org/pubs/greenpages/
Inventables
Taking items intended for one use and coming up with ideas for other innovative uses.
HalfBakery
Fun community driven half-baked ideas...
Monday, November 27, 2006
Answer Me!
One day, we were curious about what some professions could make in terms of an annual salary. After a bit of surfing around, and some wide-spectrum answers, I decided to try yahoo answers. A friend had mentioned that it was interesting, and I needed to take a look at how it worked.
Well, Yahoo Answers turns out to be a place where you can ask anything, in free-form text, and it's routed to everyone online on that site. They can answer you, which then, in turn, gets moderated by other viewers to a most/least favorable answer. In the end a single best answer matches each question. The entire process takes about 3 weeks from question asked to best answer decided.
After setting up my account, I asked my question and instantly became bored with waiting for an answer. So, I began to look over the questions other people were asking. Most, as it turns out, are mundane.
Folks ask baiting questions regarding debates long-since abandoned in their real lives. Religion, Politics, flame wars, etc. Every old misconception is put back into the mix with a stream of questions usually left to chat-room fodder.
As with most things Yahoo, Answers categorizes things into rough topic that help narrow your viewing down to just a subset of all questions/answers. So, you can view the "Computers->Security" or "Relationships->Dating" topics and wade through nonsense of your desired flavor.
Such nonsense! Yahoo Answers seem in reality to be an interface catering to web surfers that don't want to deal with Google keywords, lists of relevant web pages, or skimming information out of web sites' forum discussions, new articles, etc. They don't want to research an answer, they want it done for them. For the most part, if the question isn't too poorly constructed or heavily opinionated, they get one.
Homework answers appear, paste-jobs from wikipedia, repeat answers from prior yahoo questions. People even go through the effort to answer "I don't know" to many questions, believing this to be more informative than no answer at all(?) But shouldn't we expect the web to get closer to this level of interaction? isn't everyone hoping for the Star Trek "computer, beam me a beer" interface? Sure, but this is not a step in that direction.
So, is this the next layer of web? Has the web gotten any closer to being able to converse with you in natural language, with well-thought-out answers to your questions?
No. It is interesting, since a human layer is taking over the "last mile" of parsing information already on the web into a specific answer for your question, but the level of intelligence is distinctly human. Gone is the wikipedia "just the facts" tone, and for popular subjects (celebrities, politics, religion, sports - rivalries of almost any kind) you are going to get a squabbling mass of deluded neophytes. Even technical questions are answered with "Duh! you need to do this..." or sly commercials for tangential products or probably best, no answer at all.
But if the answers are bad, the questions do not lack for innane content and delivery. Questions such as "Apple/Microsoft? Which, um is like, the best" (not made up) indicate indeed, the questioners and answerers are in fact the same social group.
Lest you think this is a snap judgement, I've gone on to answer almost 150 questions, creating the "voted best answer" 38% of the time, over the period of about a month.
I cannot say the population isn't diverse, it is. There are professionals, students, young, old, smart asses and serious teacher-types. But for all the "buzz" of having a live person answer your burning question, you get more often than not, a random, average person's opinion, not an expert's direction. For that, Yahoo may have to build yet another layer.
That's my final answer.
Monday, October 09, 2006
Thursday, September 28, 2006
Wedding Photos
Well, it seems my better half and I think alike... I have posted the first round of photos from the wedding. More will follow very soon. Click the photo to visit the gallery.
About our photographer: we hired Teness Herman, and had the honor of being her very first Oregon wedding. In spite of relocating to Portland earlier this year, she still does most of her work in Los Angeles. She is amazingly talented, and wonderful to work with. You can visit her website to see more of her work.
Tell her the Meyers sent you. :)
Wednesday, September 27, 2006
Married
We're back y'all! The photos from all the activities are slowly rolling in, but everything went perfectly. We are very much indebted to our family and friends who helped us create such a memorable event.
Over the next few weeks, look for more posts here with stories and photos from the Big Day, and the post adventure honeymoon in in the UK and Ireland.
Tuesday, September 05, 2006
Stop The Presses!
Well friends, it's close to time to again take a break. Every 6 months or so, we take almost a month and get out of town. Each time, we raise the stakes a bit and go for a bigger adventure. "After so much, what could you possibly do now?" you ask? Ha.
We're getting married.
As in the above, our good friend Christina will officiate a small wedding of us and our 75 closest friends & family. It'll be Saturday evening, and lots of folks are coming from Pennsylvania, Washington, California, North Carolina and Oregon. For the first time, our families will meet and hang out for a few days.
At this very moment, we've been sprucing up the house, finalizing the music selection, printing the programs, and all the other pieces (food, flowers, outfits, etc).
After the big day, we are hiding away in Ireland for a few weeks. Please don't look for us. We'll be Out Of Contact for a bit. Heehee!
After our little trip, we'll be home and ready for some low-stress days. The combination of focus on your partner (a good thing) plus make the wedding your style (another good thing, but lots to decide upon) plus all the questions and things we want to include (a slide show, our own MP3's, nice favors, a quartet, etc). It's fun, but just so much that having it simply all *happen* will be a nice relief.
We're not stressing once each plan is made, but there are lots of things to set up. In the end, if dogs run through the buffet and topples the cake, so be it. (Coincidentally, this was the last time "Fluffy The Cat" was ever seen on The Brady Bunch. No shit! Look up up!).
Meanwhile, Bobby will be caring for the dogs.
Malo has a hurt paw, so that might be a little more than usual, but Malo will manage. He usually takes good care of Bob, making sure he gets plenty to eat. If you feel like stopping by to say hello, I'm sure Malo will enjoy the company while he heals up.
So thanks for the well-wishes, and see you with some more foggy photos when we get back.
Think about this year's costume party. Get back to us on that.
We're getting married.
As in the above, our good friend Christina will officiate a small wedding of us and our 75 closest friends & family. It'll be Saturday evening, and lots of folks are coming from Pennsylvania, Washington, California, North Carolina and Oregon. For the first time, our families will meet and hang out for a few days.
At this very moment, we've been sprucing up the house, finalizing the music selection, printing the programs, and all the other pieces (food, flowers, outfits, etc).
After the big day, we are hiding away in Ireland for a few weeks. Please don't look for us. We'll be Out Of Contact for a bit. Heehee!
After our little trip, we'll be home and ready for some low-stress days. The combination of focus on your partner (a good thing) plus make the wedding your style (another good thing, but lots to decide upon) plus all the questions and things we want to include (a slide show, our own MP3's, nice favors, a quartet, etc). It's fun, but just so much that having it simply all *happen* will be a nice relief.
We're not stressing once each plan is made, but there are lots of things to set up. In the end, if dogs run through the buffet and topples the cake, so be it. (Coincidentally, this was the last time "Fluffy The Cat" was ever seen on The Brady Bunch. No shit! Look up up!).
Meanwhile, Bobby will be caring for the dogs.
Malo has a hurt paw, so that might be a little more than usual, but Malo will manage. He usually takes good care of Bob, making sure he gets plenty to eat. If you feel like stopping by to say hello, I'm sure Malo will enjoy the company while he heals up.
So thanks for the well-wishes, and see you with some more foggy photos when we get back.
Think about this year's costume party. Get back to us on that.
Saturday, August 19, 2006
Sounds Like Nonsense
Started a base platform for us to play with...vocals! Being a huge singer myself, I don't mind trying - really, it's the topic to choose. I think it'll have to continue the "absurdist" theme.
The song so far is short, unmastered, and composed entirely on the road with just clips from the web(!) This little laptop is a 1-pound amateur studio, and it's fun!
The song so far is short, unmastered, and composed entirely on the road with just clips from the web(!) This little laptop is a 1-pound amateur studio, and it's fun!
Tuesday, August 15, 2006
Vacation - Part 2
Some great photos from our South America tour. There are over 5000 photos from this trip, and so many stories and events that we cannot begin to wrap our arms around it all. Suffice it to say that our trip was excellent and these snapshots are a quick skip through some of the places. We would also like to introduce Cristian and Vanessa, our two favorite people on the whole continent!
A Mapuche Indian woman gives us a blessing of good fortune using young eucalyptus leaves. She approved of Hanmi and I picking up Cristian and Vanessa hitchhiking and all of us traveling together. By keeping the blessed leaves in our wallets, "money would soon replace it." I can say that the leaf dried out and fell apart, but everyone who got my bills after that got some sweet-smelling money. Overall, we did feel blessed with a wealth of new experiences.
Our 2-room cabin, complete with wood stove and running water. This was our home for 3 days of the trip. It was both beautiful and sparse.
In the tiny fishing town of Bucalemu, Hanmi and I strolled along the promenade, soaking up the sun and the quaint images.
Vanessa, Cristian, Hanmi and I practice some slacklining with a climber friend's gear. They were passing through for the night and decided to set it up on the trees. It was tough!
Sunset in the busy town of Pucón. This was a waypoint for a lot of tourists, but it had some nice restaurants and we restocked our camping supplies. Very much like a Chilean version of Jackson, Wyoming. It was too touristy for us to stay overnight, though.
Some beautiful mountains peaks (we have dozens of shots of all kinds of peaks) along the border between Chile and Argentina.
Swimming in the "termas" (hot springs) that warm the snow melt from Mt. Villarrica, several miles away. Portions of the valley held natural steaming-hot pools, and this one was just captured water from the rushing river, built from logs. Very relaxing!
Vanessa's pet tarantula. Hanmi didn't mind goofing around with it. I almost fainted just holding it. Not a fan of spiders on my skin.
Some beautiful relief work done along an old, almost abandoned shipbuilding town in Buenos Aires
Relaxing after a cold swim on one of the nights of our Chilean adventure. Cristian and Vanessa shared their favorite foods with us (hot dogs!), and we tried to show them how to cook potatoes in the fire.
Some colorful and fun bike-based merchants in the farmers market in Chillán, along the route between Santiago and Pucon.
The four adventurers return back to Santiago after a long drive. Cristian and Vanessa's families were both very nice, hosting us and making us feel very welcome. We will be visiting them again in 2007, I think!
A Mapuche Indian woman gives us a blessing of good fortune using young eucalyptus leaves. She approved of Hanmi and I picking up Cristian and Vanessa hitchhiking and all of us traveling together. By keeping the blessed leaves in our wallets, "money would soon replace it." I can say that the leaf dried out and fell apart, but everyone who got my bills after that got some sweet-smelling money. Overall, we did feel blessed with a wealth of new experiences.
Our 2-room cabin, complete with wood stove and running water. This was our home for 3 days of the trip. It was both beautiful and sparse.
In the tiny fishing town of Bucalemu, Hanmi and I strolled along the promenade, soaking up the sun and the quaint images.
Vanessa, Cristian, Hanmi and I practice some slacklining with a climber friend's gear. They were passing through for the night and decided to set it up on the trees. It was tough!
Sunset in the busy town of Pucón. This was a waypoint for a lot of tourists, but it had some nice restaurants and we restocked our camping supplies. Very much like a Chilean version of Jackson, Wyoming. It was too touristy for us to stay overnight, though.
Some beautiful mountains peaks (we have dozens of shots of all kinds of peaks) along the border between Chile and Argentina.
Swimming in the "termas" (hot springs) that warm the snow melt from Mt. Villarrica, several miles away. Portions of the valley held natural steaming-hot pools, and this one was just captured water from the rushing river, built from logs. Very relaxing!
Vanessa's pet tarantula. Hanmi didn't mind goofing around with it. I almost fainted just holding it. Not a fan of spiders on my skin.
Some beautiful relief work done along an old, almost abandoned shipbuilding town in Buenos Aires
Relaxing after a cold swim on one of the nights of our Chilean adventure. Cristian and Vanessa shared their favorite foods with us (hot dogs!), and we tried to show them how to cook potatoes in the fire.
Some colorful and fun bike-based merchants in the farmers market in Chillán, along the route between Santiago and Pucon.
The four adventurers return back to Santiago after a long drive. Cristian and Vanessa's families were both very nice, hosting us and making us feel very welcome. We will be visiting them again in 2007, I think!
Thursday, August 10, 2006
Staring at code from across the sea
Offshore programming seems to be a hot issue in the past few years. Well, I'm on my third placement as a software engineer reviewing the output of code written from India. I can't generalize the entire industry from the evidence I've seen, but in this short experience there are some depressing patterns.
You can't ask for a piece of technology without clear requirements, many of which are only flushed out as development starts to present a partly-complete product. "Oh, I want something like this, but more of..." is a common sentiment of the requester. So, iteration and involvement are key concepts in this endeavor. The problem is, if you do this too late in the process, you have to pay for the un-building of some parts to accommodate your changes. Ok, so this much is obvious. Already, one can see that putting a development team far away from the customer would present a hurdle to a smooth flow of communication.
The programming industry has two levels: "SELL/DELIVER!" - The personality who wants to focus on getting the requests met quickly and within budget. Then there's "ANALYZE/ADVISE!" - The personality seeks to focus on flushing out all the details so that the request is clear and potential issues are resolved before its too late.
Both of these are in balance the entire way. Too much on either side and problems arise: SELL/DELIVER will release a product that does everything initially asked, but it's not very dynamic. The product needs a lot of effort to adjust to the real-world, which is always in flux. "We want to add to this..." can be a death-knell for a product that hasn't thought about so-called "Flex Points." Flex Points are the software equivalent of "ways to accommodating change." If you built a swing set, you wouldn't weld the chains to the seat, because the chains may need to be lengthened or shortened at some point. Well, without a flex point, a change's effort is higher - this means expensive. This lack of flexibility can become apparent even before the project is released - which early on is a relatively better find, since 1 delay to install a flex point is better than years of expensive changes.
Conversely, too much focus on the ANALYZE/ADVISE can have other adverse effects: First, you may have to start defending longer and longer periods of design and discussion about "what are we going to do?" without yet delivering product parts (this criticism is due in part to the miss-classification of analysis as "non-work" by some of the other camp). One ends up with a large amount of descriptive information about a project. For the most part, many folks view this as a Good Thing. However, documentation is sometimes unnecessary: only what is read later or presented to the customer for discussion is useful. The rest is bloat. Also if the construction team is the same as the analysis team, documenting the entire system is usually unnecessary, since they will soon be iterating prototypes and early releases to the client. The formalization of the design documents is best used when handing the design to another team - like an offshore team. At that point, a whole new set of risks arise.
Similar to the value of Design Documents that only have value if used, the Flex Points built into software are only valuable once *used*. Before that, they are effort (investment) in anticipation of change. One must draw a line between how much change you will accommodate in an initial design, and how much work an enhancement may entail. There are advantages to each - one makes work analogous to "entering a record in the table" or "changing a value in the profile" versus "rework the logic and recompile." For example, if you anticipate a future of your swing set that may allow for a tree house on top of it, you invest a lot of effort in the construction of the base level. If your guess is wrong and no tree house is ever needed, that cost was needless. One shouldn't speculate on the market when building in Flex Points. Instead, you leave those changes up to another release, which requires not Flex Points, but Modular Design. Modular Design suggests that you can hang the swings from another, different frame in the future without a lot of effort, and save the design of a 2-story swing set with tree house for another project. In software, this is essentially building-in a low coupling between components, anticipating that entire components, while not flexible enough initially, can be rewritten and then replace the prior component without disturbing the entire system.
As an aside, this is why XML as a communication encoding gained popularity. Each component in the application can read when it needs from the information flowing around, and ignore other parts. XML alone doesn't make this happen, but the standard tools for using XML-encoded data facilitate this easily. Other components in the system can ignore the new data a future releases start adding to the data, until individual replacement components can take advantage of such data. Meanwhile, existing components need not be touched, saving a large part of the testing and code management costs.
In an offshore project, you typically have a team show up at your doorstep to flush out a design. If they are going to write it, one suspects you no longer need any software experts in-house to help. However, this is the mistake I've been hired to clean up time and again: The software Delivered but severely lacked on both the Flex Points and the Modular Design approaches. The team analyzed the problem to solve, but never seemed to ask questions about what the customer envisioned in their future, and never presented a menu of trade-offs of flexibility/cost to the customer.
Thus, at some point after the birthing process of the project (a big deal), the perceived "win" degrades. The market or business needs hit the software and it cannot change easily. Each programmer diving into the product tells the customer "this wasn't written to accommodate what you're asking" and the customer is left frustrated in paying more for changes than they expected. Changing the system not longer mimics a replacement of parts wired lightly together; it resembles delicate surgery.
Note, personally I tell customers 2 things when starting to design a system: (1) The balance of what any team, customer or consultant, can foresee is limited. One must focus on productive concepts and modular design that can grow easily. Change will always cost something, but minimizing it is in everyone's best interest. (2) The initial analysis has two parts: the business problem we're solving and the technical description of the Flex Points and Modules. This mean the analysis make take a bit longer than expected, but it reduces the risk of making a poor decision.
Thankfully, software engineering principles of the last five years have taken this into account. Multiple technology layers have arisen that allow for Flex Points and Modular Design to be easily incorporated into a platform. The Object-Oriented drive of software in the prior 15 years has matured into a distributed component-oriented design. Web Services, XML, object frameworks, and a multitude of standard toolsets from large vendors make this easy. The only drawback to a business is training their programmers to understanding and using these principles. Younger programmers may learn this in school, but older programmers usually know the business data better. Solution Space (modern design) versus Problem Space (business data relationships). Both must be merged and used together.
This again comes back to a drawback of offshore programming: The Business Data relationships have to be completely flushed out and communicated clearly to a team that more-often-than-not doesn't understand the client's market. Now the skills of the Business Analyst comes into play, and low skills here can spell disaster when the Offshore team assumes relationships about the data which later prove to be false. Instead, using in-house developers or at least market-aware consultants allow the "right questions to be asked" as managers are fond of saying.
Given my experience, a business should prioritize the acquisition of software in tiers:
1:
If the issue is market-wide and not a custom need and solved with a common tool – use one! One doesn't usually see companies writing their own Email clients, for example. The commodization of tools such as those is mature and sufficiently flexible. Some tools allow for significant customization, which can encompass the usage pattern of the customer ("we need extra fields in our email..." for example). For highly dynamic requirements, perhaps a large-vendor solution suffices (Lotus Notes communication platform), but one must start to examine why a customer needs such a level of dynamics in a common tool area. Continuing the example, this would be when a customer demands a custom email tool because their needs are beyond market tools - I begin to ask "Are you asking for features in the wrong part of the information flow?" Perhaps a combination of tools or another path accommodates the request. Technology knowledge can trump a savvy Business Analyst here, who sees an all-in-one tool when really a set of of-the-shelf tools integrated elegantly would suffice.
2:
If the business need is truly custom and dynamic, then writing a tool is probably necessary. Using any in-house developers is almost always a better investment, all other factors unchanged. Low morale, high turnover, and other issues of a workforce can make programmer training seem like a waste (indeed, training is doubly expensive, since more knowledgeable programmers can compete in a more expensive market for wages). But for a team that actually enjoys creating great solutions, an interesting project that provides real value to the business is always a win-win between programmer and business. For a business the ROI of highly skilled programmers can be realized over several projects. This implies a need for standardization on the solutions platforms. Managers that demand or suggest diverse platforms, and thus diverse skill sets, usually end up juggling too many workforce skills to know their team well. Consolidation on a robust platform is an easy bet.
3:
Bringing in help to augment a team can be beneficial. One note on that: Sequestering contractors away from the salaried folks (due to perceived secrecy or other politics) only ends up preventing the contractors needed skills from migrating to the people who will be maintaining the system long-term. I've seen businesses treat contractors like peasants, uninvited from most meetings and such - but then they are trusted to provide a much-needed skill and deal with some of the most delicate business data. This resulted in disaster when the contractor left, since a new one with the same skills had to immediately take their place. Although it benefits a contractor to be constantly in the "savior" position (it's quite lucrative!), a true consultant advises a business to take over the system entirely - training the team as the system is built. So, contractors are best used in pairs or teams.
4:
Lastly, as much as I've argued against remote development, it can be used constructively. I would advise businesses to allow their development team to break a solution into modules, allowing the remote team to deliver the modules piecemeal, and have the in-house team integrate them. This allows for the guidance on standards and the quality of the remote team to be reviewed in an iterative manner. Remember, this still means involvement of the local team to a large degree. They are designing the unit tests for the modules, which are written and run by the remote team. The local team is also reviewing the code of the modules. Obviously, they are performing the system testing.
Overall, there’s no such thing as a Done System. The closer software is to aiding in businesses processes, the more dynamic and maintainable it must be. The skills to manipulate it must be common in the market and familiar to the in-house developers. Training, paired with direct usage of the new skills on in-house projects, is a necessary part of keeping a team happy. This does not mean “adopting new technologies” so much as “going deep” on the decided platforms already in-house.
“Turning the ship” of a company can be frustrating and involving and lot of pontificating and preaching, but if the effects of poor decisions can be predicted, a business will notice. If you see your client or company making an obvious mistake in your eyes, speak up and be ready to listen. Papers such as this aren’t the only place wisdom can be imparted.
You can't ask for a piece of technology without clear requirements, many of which are only flushed out as development starts to present a partly-complete product. "Oh, I want something like this, but more of..." is a common sentiment of the requester. So, iteration and involvement are key concepts in this endeavor. The problem is, if you do this too late in the process, you have to pay for the un-building of some parts to accommodate your changes. Ok, so this much is obvious. Already, one can see that putting a development team far away from the customer would present a hurdle to a smooth flow of communication.
The programming industry has two levels: "SELL/DELIVER!" - The personality who wants to focus on getting the requests met quickly and within budget. Then there's "ANALYZE/ADVISE!" - The personality seeks to focus on flushing out all the details so that the request is clear and potential issues are resolved before its too late.
Both of these are in balance the entire way. Too much on either side and problems arise: SELL/DELIVER will release a product that does everything initially asked, but it's not very dynamic. The product needs a lot of effort to adjust to the real-world, which is always in flux. "We want to add to this..." can be a death-knell for a product that hasn't thought about so-called "Flex Points." Flex Points are the software equivalent of "ways to accommodating change." If you built a swing set, you wouldn't weld the chains to the seat, because the chains may need to be lengthened or shortened at some point. Well, without a flex point, a change's effort is higher - this means expensive. This lack of flexibility can become apparent even before the project is released - which early on is a relatively better find, since 1 delay to install a flex point is better than years of expensive changes.
Conversely, too much focus on the ANALYZE/ADVISE can have other adverse effects: First, you may have to start defending longer and longer periods of design and discussion about "what are we going to do?" without yet delivering product parts (this criticism is due in part to the miss-classification of analysis as "non-work" by some of the other camp). One ends up with a large amount of descriptive information about a project. For the most part, many folks view this as a Good Thing. However, documentation is sometimes unnecessary: only what is read later or presented to the customer for discussion is useful. The rest is bloat. Also if the construction team is the same as the analysis team, documenting the entire system is usually unnecessary, since they will soon be iterating prototypes and early releases to the client. The formalization of the design documents is best used when handing the design to another team - like an offshore team. At that point, a whole new set of risks arise.
Similar to the value of Design Documents that only have value if used, the Flex Points built into software are only valuable once *used*. Before that, they are effort (investment) in anticipation of change. One must draw a line between how much change you will accommodate in an initial design, and how much work an enhancement may entail. There are advantages to each - one makes work analogous to "entering a record in the table" or "changing a value in the profile" versus "rework the logic and recompile." For example, if you anticipate a future of your swing set that may allow for a tree house on top of it, you invest a lot of effort in the construction of the base level. If your guess is wrong and no tree house is ever needed, that cost was needless. One shouldn't speculate on the market when building in Flex Points. Instead, you leave those changes up to another release, which requires not Flex Points, but Modular Design. Modular Design suggests that you can hang the swings from another, different frame in the future without a lot of effort, and save the design of a 2-story swing set with tree house for another project. In software, this is essentially building-in a low coupling between components, anticipating that entire components, while not flexible enough initially, can be rewritten and then replace the prior component without disturbing the entire system.
As an aside, this is why XML as a communication encoding gained popularity. Each component in the application can read when it needs from the information flowing around, and ignore other parts. XML alone doesn't make this happen, but the standard tools for using XML-encoded data facilitate this easily. Other components in the system can ignore the new data a future releases start adding to the data, until individual replacement components can take advantage of such data. Meanwhile, existing components need not be touched, saving a large part of the testing and code management costs.
In an offshore project, you typically have a team show up at your doorstep to flush out a design. If they are going to write it, one suspects you no longer need any software experts in-house to help. However, this is the mistake I've been hired to clean up time and again: The software Delivered but severely lacked on both the Flex Points and the Modular Design approaches. The team analyzed the problem to solve, but never seemed to ask questions about what the customer envisioned in their future, and never presented a menu of trade-offs of flexibility/cost to the customer.
Thus, at some point after the birthing process of the project (a big deal), the perceived "win" degrades. The market or business needs hit the software and it cannot change easily. Each programmer diving into the product tells the customer "this wasn't written to accommodate what you're asking" and the customer is left frustrated in paying more for changes than they expected. Changing the system not longer mimics a replacement of parts wired lightly together; it resembles delicate surgery.
Note, personally I tell customers 2 things when starting to design a system: (1) The balance of what any team, customer or consultant, can foresee is limited. One must focus on productive concepts and modular design that can grow easily. Change will always cost something, but minimizing it is in everyone's best interest. (2) The initial analysis has two parts: the business problem we're solving and the technical description of the Flex Points and Modules. This mean the analysis make take a bit longer than expected, but it reduces the risk of making a poor decision.
Thankfully, software engineering principles of the last five years have taken this into account. Multiple technology layers have arisen that allow for Flex Points and Modular Design to be easily incorporated into a platform. The Object-Oriented drive of software in the prior 15 years has matured into a distributed component-oriented design. Web Services, XML, object frameworks, and a multitude of standard toolsets from large vendors make this easy. The only drawback to a business is training their programmers to understanding and using these principles. Younger programmers may learn this in school, but older programmers usually know the business data better. Solution Space (modern design) versus Problem Space (business data relationships). Both must be merged and used together.
This again comes back to a drawback of offshore programming: The Business Data relationships have to be completely flushed out and communicated clearly to a team that more-often-than-not doesn't understand the client's market. Now the skills of the Business Analyst comes into play, and low skills here can spell disaster when the Offshore team assumes relationships about the data which later prove to be false. Instead, using in-house developers or at least market-aware consultants allow the "right questions to be asked" as managers are fond of saying.
Given my experience, a business should prioritize the acquisition of software in tiers:
1:
If the issue is market-wide and not a custom need and solved with a common tool – use one! One doesn't usually see companies writing their own Email clients, for example. The commodization of tools such as those is mature and sufficiently flexible. Some tools allow for significant customization, which can encompass the usage pattern of the customer ("we need extra fields in our email..." for example). For highly dynamic requirements, perhaps a large-vendor solution suffices (Lotus Notes communication platform), but one must start to examine why a customer needs such a level of dynamics in a common tool area. Continuing the example, this would be when a customer demands a custom email tool because their needs are beyond market tools - I begin to ask "Are you asking for features in the wrong part of the information flow?" Perhaps a combination of tools or another path accommodates the request. Technology knowledge can trump a savvy Business Analyst here, who sees an all-in-one tool when really a set of of-the-shelf tools integrated elegantly would suffice.
2:
If the business need is truly custom and dynamic, then writing a tool is probably necessary. Using any in-house developers is almost always a better investment, all other factors unchanged. Low morale, high turnover, and other issues of a workforce can make programmer training seem like a waste (indeed, training is doubly expensive, since more knowledgeable programmers can compete in a more expensive market for wages). But for a team that actually enjoys creating great solutions, an interesting project that provides real value to the business is always a win-win between programmer and business. For a business the ROI of highly skilled programmers can be realized over several projects. This implies a need for standardization on the solutions platforms. Managers that demand or suggest diverse platforms, and thus diverse skill sets, usually end up juggling too many workforce skills to know their team well. Consolidation on a robust platform is an easy bet.
3:
Bringing in help to augment a team can be beneficial. One note on that: Sequestering contractors away from the salaried folks (due to perceived secrecy or other politics) only ends up preventing the contractors needed skills from migrating to the people who will be maintaining the system long-term. I've seen businesses treat contractors like peasants, uninvited from most meetings and such - but then they are trusted to provide a much-needed skill and deal with some of the most delicate business data. This resulted in disaster when the contractor left, since a new one with the same skills had to immediately take their place. Although it benefits a contractor to be constantly in the "savior" position (it's quite lucrative!), a true consultant advises a business to take over the system entirely - training the team as the system is built. So, contractors are best used in pairs or teams.
4:
Lastly, as much as I've argued against remote development, it can be used constructively. I would advise businesses to allow their development team to break a solution into modules, allowing the remote team to deliver the modules piecemeal, and have the in-house team integrate them. This allows for the guidance on standards and the quality of the remote team to be reviewed in an iterative manner. Remember, this still means involvement of the local team to a large degree. They are designing the unit tests for the modules, which are written and run by the remote team. The local team is also reviewing the code of the modules. Obviously, they are performing the system testing.
Overall, there’s no such thing as a Done System. The closer software is to aiding in businesses processes, the more dynamic and maintainable it must be. The skills to manipulate it must be common in the market and familiar to the in-house developers. Training, paired with direct usage of the new skills on in-house projects, is a necessary part of keeping a team happy. This does not mean “adopting new technologies” so much as “going deep” on the decided platforms already in-house.
“Turning the ship” of a company can be frustrating and involving and lot of pontificating and preaching, but if the effects of poor decisions can be predicted, a business will notice. If you see your client or company making an obvious mistake in your eyes, speak up and be ready to listen. Papers such as this aren’t the only place wisdom can be imparted.
Friday, July 14, 2006
Escape
After entering the funhouse in Aug 2005, I realized the warnings were true: "Do Not Challenge The Programmer" was said to me repeatedly. Here's the story of what I learned at a failing startup in the past year.
It began as an exciting departure from a few years of corporate-job software-guy doldrums. The surroundings were getting less and less exciting, and the folks I was developing with didn't want to excel at their technical expertise; they wanted traffic to go away to/from job and the 3% raise to land on them. Exciting as watching dogs poop.
So I jumped, ready for the consulting world. Except a funny thing happened along the way. I ran into some friends that were in a startup, and wanted to try and make it succeed. They were working in a neat concept and needed more help. The money was right, so I entered as full-time.
Well, one trip through the 400,000+ lines of code (for 40 screens) there gave me food for thought. It was written by someone seemingly out of touch with how client-server software is written for the past 10 years. Custom code for needless tools, buggy designs that poorly mimic things you get out of the box, etc. I took it as a challenge; the gauntlet was thrown! I was going to introduce a world of new modern designs, and turn the codebase into a humming, smaller, porche-engine of strength. Or so I thought.
"Um, who wrote all of this?" I asked. Several conversations starting like this are best condensed as:
"Oh, well GB." [name withheld to protect the crazy]
"GB? THE GB? The GB who is now CEO?"
"Yep."
Now for a company of 17 people this isn't rare. Plenty of software people get a fun idea, write it in their basement for a few years and then try to build a little company around it. However, this person was performing two roles actively: Suited CEO and investment cheerleader, and midnight-frantic programmer guy. I can't say for sure that his CEO skills were lacking - his managerial skills certainly were, but in terms of code, his output was bad. I mean, really bad. "Coding Horror", hair-on-end bad.
Innocently enough, I began to approach isolated concepts in the code and I hoped to remove their terribleness. I have dealth with student-code, monkey-faking-it-code, and i'm-quitting-tomorrow-code, all bad. So I knew exactly what needed to change in many of these cases.
"Dude. Don't challenge GB on his code." I was told.
"Oh comon - if I fix this, we save like 5 hours a month patching and searching for bugs in the whole pile. It's obsiouvsly worth it."
"Worth isn't in the equation. It's not ROA-based. It's emotional. Don't change GB's code. He loves it and thinks everyone else is wrong."
"Well I bet I can show him how this change will improve things." I said confidently.
So I scheduled a meeting and listened as he whiteboarded up why he needed to write a completely new tool. "Because we found Microsoft's one had a bug." This was perhaps true, but when the tool is quite large, one questions that path. I mean, he half-wrote a large tool to mimic an existing one because of one bug. Okay... but when i researched his described "bug" from the vendor and users (MS has a lot of data on this), I found nothing. He seemingly wrote a new tool to replace a one based *not* on a bug, but in it rejecting his bad design.
A red, swirling light blinked on for a second. Whoop! Whoop! Dive! Dive! I had to get to the bottom of how this guy was thinking.
So another meeting, actually several. He began to expain to me his worldview of programming. The dynamics he was trying to achieve. Not a bad goal, but not really part of the business plan, as I saw it. He was in love with his version of how software could be constructed, and quiet/ignorant of how easy it would be to release solid code "the usual way" way faster. He was planning for years of version changes before the prototype was ready and could run for more than a day.
I began a new project. It was a complimentary application as part of the suite they were shipping. It was to replace an existing application and augment its abilities. The business specs were vague, but the technical demands were explicit. It had to accept constant, large changes to the database schema. Why? Because there was no time to do all the analysis.
Think of that last statement. "No time to do the full analysis" - so we're going to write it to accept whatever the customer asks of us. I began to wonder what business we were in. Ideally, you could be in any business until you asked the customer "what do you want?" "Hmm. Ice cream." Okay, here's some software to make ice cream. Sheesh. So no specs, just a large number of iterative prototypes and endless tweaking. Usually this is fast, but when the CEO is out for the day, and nobody else knows for sure when "good" is "good enough", it slows to a crawl. I had to wait until the analyst hat (a small hat) was worn to get feedback.
Well, I stepped up to the challenge, and created a layer of dyanmic data that mirrored the database, but tried to shield the business logic from bombs of changing requirements. I used commonly-available code that worked throughout many companies already. I invented very little, simply reusing what folks found most productive. I was treated like an idiot.
"Why are you doing this like you are? What is the benefit?" He asked me, angrily.
"This is how modern systems are breaking up the impact of changes. The very changes you expressed were going to happen often. It's the beset practice of the industry"
"You're not listening. The market doesn't know our product. Efficiency is not effectiveness. We have a model in place."
"Your model is full of bugs, and has inherent design flaws. I didn't want to create a product that just got to the level of the current applications, but surpassed them."
"Well, now we have to maintain 2 models, and nobody knows how yours works either."
"Not true, I've used code that is fully documented, has a huge base of folks knowledgeable in it. It's from the internet and is already in working systems, not something I made up in my basement."
After a few heated meetings like this, we silently agreed to not talk to one another. Not very good for an analyst and programmer relationship. Occasionally, I'd get emails challenging my releases or designs. "Thanks for the cheerful attitude" I'd write, CC'ing the audience. I wanted to kill him with kindness. Well, actually, I just wanted the programmer to die, the CEO guy could shake hands and type memos as long as he wanted.
Now, fast forward 1 year. Cancel the "different" project because of "lateness", start the technical salvage of the code into other projects, and then present a *new* design for the such a system. (Actually, just more detail of the original design, since it was still good).
Said design is rejected, so 3 engineering members quit. I get a month to unwind and finally (remember this part?) start contracting around town. Whew! What a crazy place.
It began as an exciting departure from a few years of corporate-job software-guy doldrums. The surroundings were getting less and less exciting, and the folks I was developing with didn't want to excel at their technical expertise; they wanted traffic to go away to/from job and the 3% raise to land on them. Exciting as watching dogs poop.
So I jumped, ready for the consulting world. Except a funny thing happened along the way. I ran into some friends that were in a startup, and wanted to try and make it succeed. They were working in a neat concept and needed more help. The money was right, so I entered as full-time.
Well, one trip through the 400,000+ lines of code (for 40 screens) there gave me food for thought. It was written by someone seemingly out of touch with how client-server software is written for the past 10 years. Custom code for needless tools, buggy designs that poorly mimic things you get out of the box, etc. I took it as a challenge; the gauntlet was thrown! I was going to introduce a world of new modern designs, and turn the codebase into a humming, smaller, porche-engine of strength. Or so I thought.
"Um, who wrote all of this?" I asked. Several conversations starting like this are best condensed as:
"Oh, well GB." [name withheld to protect the crazy]
"GB? THE GB? The GB who is now CEO?"
"Yep."
Now for a company of 17 people this isn't rare. Plenty of software people get a fun idea, write it in their basement for a few years and then try to build a little company around it. However, this person was performing two roles actively: Suited CEO and investment cheerleader, and midnight-frantic programmer guy. I can't say for sure that his CEO skills were lacking - his managerial skills certainly were, but in terms of code, his output was bad. I mean, really bad. "Coding Horror", hair-on-end bad.
Innocently enough, I began to approach isolated concepts in the code and I hoped to remove their terribleness. I have dealth with student-code, monkey-faking-it-code, and i'm-quitting-tomorrow-code, all bad. So I knew exactly what needed to change in many of these cases.
"Dude. Don't challenge GB on his code." I was told.
"Oh comon - if I fix this, we save like 5 hours a month patching and searching for bugs in the whole pile. It's obsiouvsly worth it."
"Worth isn't in the equation. It's not ROA-based. It's emotional. Don't change GB's code. He loves it and thinks everyone else is wrong."
"Well I bet I can show him how this change will improve things." I said confidently.
So I scheduled a meeting and listened as he whiteboarded up why he needed to write a completely new tool. "Because we found Microsoft's one had a bug." This was perhaps true, but when the tool is quite large, one questions that path. I mean, he half-wrote a large tool to mimic an existing one because of one bug. Okay... but when i researched his described "bug" from the vendor and users (MS has a lot of data on this), I found nothing. He seemingly wrote a new tool to replace a one based *not* on a bug, but in it rejecting his bad design.
A red, swirling light blinked on for a second. Whoop! Whoop! Dive! Dive! I had to get to the bottom of how this guy was thinking.
So another meeting, actually several. He began to expain to me his worldview of programming. The dynamics he was trying to achieve. Not a bad goal, but not really part of the business plan, as I saw it. He was in love with his version of how software could be constructed, and quiet/ignorant of how easy it would be to release solid code "the usual way" way faster. He was planning for years of version changes before the prototype was ready and could run for more than a day.
I began a new project. It was a complimentary application as part of the suite they were shipping. It was to replace an existing application and augment its abilities. The business specs were vague, but the technical demands were explicit. It had to accept constant, large changes to the database schema. Why? Because there was no time to do all the analysis.
Think of that last statement. "No time to do the full analysis" - so we're going to write it to accept whatever the customer asks of us. I began to wonder what business we were in. Ideally, you could be in any business until you asked the customer "what do you want?" "Hmm. Ice cream." Okay, here's some software to make ice cream. Sheesh. So no specs, just a large number of iterative prototypes and endless tweaking. Usually this is fast, but when the CEO is out for the day, and nobody else knows for sure when "good" is "good enough", it slows to a crawl. I had to wait until the analyst hat (a small hat) was worn to get feedback.
Well, I stepped up to the challenge, and created a layer of dyanmic data that mirrored the database, but tried to shield the business logic from bombs of changing requirements. I used commonly-available code that worked throughout many companies already. I invented very little, simply reusing what folks found most productive. I was treated like an idiot.
"Why are you doing this like you are? What is the benefit?" He asked me, angrily.
"This is how modern systems are breaking up the impact of changes. The very changes you expressed were going to happen often. It's the beset practice of the industry"
"You're not listening. The market doesn't know our product. Efficiency is not effectiveness. We have a model in place."
"Your model is full of bugs, and has inherent design flaws. I didn't want to create a product that just got to the level of the current applications, but surpassed them."
"Well, now we have to maintain 2 models, and nobody knows how yours works either."
"Not true, I've used code that is fully documented, has a huge base of folks knowledgeable in it. It's from the internet and is already in working systems, not something I made up in my basement."
After a few heated meetings like this, we silently agreed to not talk to one another. Not very good for an analyst and programmer relationship. Occasionally, I'd get emails challenging my releases or designs. "Thanks for the cheerful attitude" I'd write, CC'ing the audience. I wanted to kill him with kindness. Well, actually, I just wanted the programmer to die, the CEO guy could shake hands and type memos as long as he wanted.
Now, fast forward 1 year. Cancel the "different" project because of "lateness", start the technical salvage of the code into other projects, and then present a *new* design for the such a system. (Actually, just more detail of the original design, since it was still good).
Said design is rejected, so 3 engineering members quit. I get a month to unwind and finally (remember this part?) start contracting around town. Whew! What a crazy place.
Sunday, June 25, 2006
The Flow
The waveboards are great fun. We've used them to go up and down streets for 2 weeks now. They give a good workout and roll pretty quickly. In fact, they seem to roll too quickly! After an evening at Tabor, I was bummed from having to "jump and roll" so often after the board got really moving. It seems like turning to "carve" on a waveboard just doesn't deliver enough friction to slow you down. Carving then, is short progression from super fun to insane panic, then dumping.
Enter the Flowboard. Han picked up a pair of these for some fun downhilling. And man, they are perfect! Now, on flat streets they ride much more like a regular skateboard. But on hills, they allow you to really dig into a turn, and the sideward friction does indeed slow you down.
Pumping around on a flowboard is a bit tougher, since they wobble like the trucks are loose on a regular skateboard, but I've taken that challenge up on my calf muscules, which are always up for a workout. Riding down (and up) curbs is pretty standard. In fact, the flowboard is so similar to a standard skateboard, I'll probably use it a bit more than the Waveboard. But no matter, either is great fun!
J
Enter the Flowboard. Han picked up a pair of these for some fun downhilling. And man, they are perfect! Now, on flat streets they ride much more like a regular skateboard. But on hills, they allow you to really dig into a turn, and the sideward friction does indeed slow you down.
Pumping around on a flowboard is a bit tougher, since they wobble like the trucks are loose on a regular skateboard, but I've taken that challenge up on my calf muscules, which are always up for a workout. Riding down (and up) curbs is pretty standard. In fact, the flowboard is so similar to a standard skateboard, I'll probably use it a bit more than the Waveboard. But no matter, either is great fun!
J
Thursday, June 15, 2006
Love letters
Last month I spent a couple weeks traveling in Asia for work. This post is not about that trip, however. Instead, I wanted to share a snippet of hilarity sent amidst the love letters Jim sent from home. I had been off the grid for a couple days when I read the following, and it literally made tears squirt forth from my eyes as burst into screaming laughter... your results may vary... enjoy!
"Malo must have swallowed some salt water during his swimming adventure (we all went in the cold cold water today). On the way home, his ass burst so violently that he ended up on the front floor. I cannot describe how awful the carnage was. He shot a turd directly into the passenger seat, along with a belly of poopy salt water. It was a crazy awful brown circular smear about 8 inches across the seat, splashed onto everything nearby. I was screaming like a horror movie. We almost went into a ditch. It just exploded. I was wondering why he was crying. I have to start listening to that.
In other news, the car was washed. The seats are in the washing machine, and there's a Seaside junior high team with 20 of my dollars. I made them work hard for them - external only, but wheels, roof, windows, anything I could think of. Internally, I'm going to have to clean and disinfect the cabin. We all had our head out the window on the way home, looking quite queasy. It was rank enough to make the prom kids wince as I pulled up to the red light downtown."
The Wave
Recently, a friend was at a party and rode an interesting device called 'The Wave'. Born of a skateboard, but modified to make every part fluid, he described it to us. "Good workout", "hard to learn", "looks funky", etc.
After 10 minutes watching videos of it, we hopped over to Amazon and bought a pair. 2 weeks later, we "worked from home" to open a package the moment it arrived. Bike helmets and gloves on, here's a quick review:
The Wave comes with a short bit of printed material, a mis-sized allen wrench and an 8-minute DVD that duplicates the web site content. Trash. Get your own wrench if you want, but it won't change much on the board. Read the booklet, toss the DVD.
In the street, we used the cars along the side to right ourselves and start sliding. Definitely begin facing downhill on a moderate slope. Starting is harder than continuing. Pumping the board to move forward isn't tough to learn. It is quite a work out, however.
Also, be ready to "dump and roll" on the big hills. Carving is smooth and exciting, but it does not slow the board as much as a normal skateboard. You will continuously gain speed until you cry and jump - or until the hill bottoms out.
The Wave is mostly plastic, and rides with a bit of rickety noise from the torsion bar vibrating in its housing. The wheels, casters and bearings are very smooth. The action of riding and turning wears the wheels evenly. While riding, your feet cannot easily leave the board for a "push", so the wiggle-method of propulsion is it, so mastering it is key. One can use kicking legs or a full hula-hoop dance to move forward, but either can climb small inclines.
There are few things to do with the board after riding it. I started spray-painting and sticker-ing mine, but there's little good surface. The board is only slightly heavier than a normal skateboard, and can be carried easily. Small bumps or cracks in the surface aren't much of a problem, and the rider can quickly get over whatever is in range for the wheel diameter.
The torsion bar is fairly weak, even at full crank. This doesn't matter much, since one doesn't rely on it while riding. The friction of the top surface is key, since one needs the feet to stick when the board is twisted. Wet surfaces are a disaster because all of the movement of the wave is in a curve. Wrists and elbows will be the final judge.
Taking The Wave on a packed trail, I was able to roll quite a bit. However, the small diameter wheels forced me onto only the flattest trails (well let's say, it forced me off of all others). Also, the lbs/sq inch of the 2 wheels is higher, demanding a harder surface than a normal skateboard. One spectacular dive was spawned from a trail that suddenly went soft, throwing me sideways at a good clip.
Since you are positioned in "snowboard" stance, rather than facing forward, dumping is not easy. You must jump, turn in the air to face forward, then perform the usual foot-slapping run to slow down. The board slides to the stop quickly, which is better than the traditional runaway skateboard.
Overall, I think this is a great addition to anyone's toybox. You definitely look like an overgrown kid. Be prepared for lots of comments and questions from the curious. Avoid letting kids try it, since they will possibly end up with a mouth full of asphalt and legal hand on your wallet.
Check back soon for helmet cam vids of my adventures on this device.
After 10 minutes watching videos of it, we hopped over to Amazon and bought a pair. 2 weeks later, we "worked from home" to open a package the moment it arrived. Bike helmets and gloves on, here's a quick review:
The Wave comes with a short bit of printed material, a mis-sized allen wrench and an 8-minute DVD that duplicates the web site content. Trash. Get your own wrench if you want, but it won't change much on the board. Read the booklet, toss the DVD.
In the street, we used the cars along the side to right ourselves and start sliding. Definitely begin facing downhill on a moderate slope. Starting is harder than continuing. Pumping the board to move forward isn't tough to learn. It is quite a work out, however.
Also, be ready to "dump and roll" on the big hills. Carving is smooth and exciting, but it does not slow the board as much as a normal skateboard. You will continuously gain speed until you cry and jump - or until the hill bottoms out.
The Wave is mostly plastic, and rides with a bit of rickety noise from the torsion bar vibrating in its housing. The wheels, casters and bearings are very smooth. The action of riding and turning wears the wheels evenly. While riding, your feet cannot easily leave the board for a "push", so the wiggle-method of propulsion is it, so mastering it is key. One can use kicking legs or a full hula-hoop dance to move forward, but either can climb small inclines.
There are few things to do with the board after riding it. I started spray-painting and sticker-ing mine, but there's little good surface. The board is only slightly heavier than a normal skateboard, and can be carried easily. Small bumps or cracks in the surface aren't much of a problem, and the rider can quickly get over whatever is in range for the wheel diameter.
The torsion bar is fairly weak, even at full crank. This doesn't matter much, since one doesn't rely on it while riding. The friction of the top surface is key, since one needs the feet to stick when the board is twisted. Wet surfaces are a disaster because all of the movement of the wave is in a curve. Wrists and elbows will be the final judge.
Taking The Wave on a packed trail, I was able to roll quite a bit. However, the small diameter wheels forced me onto only the flattest trails (well let's say, it forced me off of all others). Also, the lbs/sq inch of the 2 wheels is higher, demanding a harder surface than a normal skateboard. One spectacular dive was spawned from a trail that suddenly went soft, throwing me sideways at a good clip.
Since you are positioned in "snowboard" stance, rather than facing forward, dumping is not easy. You must jump, turn in the air to face forward, then perform the usual foot-slapping run to slow down. The board slides to the stop quickly, which is better than the traditional runaway skateboard.
Overall, I think this is a great addition to anyone's toybox. You definitely look like an overgrown kid. Be prepared for lots of comments and questions from the curious. Avoid letting kids try it, since they will possibly end up with a mouth full of asphalt and legal hand on your wallet.
Check back soon for helmet cam vids of my adventures on this device.
Friday, February 24, 2006
Vacation - Part I
We went to South America and had a great time. Flew into Buenos Aries, stayed at the chic "Art Hotel" for 2 days, then hopped over to Santiago, Chile. We stayed there for 2 more days, then rented a car and drove south, and south, and south. Chile is a tall country, but there's quite a bit of interesting stuff along the way. We rock climbed, camped, met lots of interesting people, including the grandaughter of a mapuchi indian chief, and spoke a lot of hilariously bad spanish. We drove back to Santiago, flew to BA for another day, then headed home. Overall it was a 3 week vacation.
First, while in Buenos Aries outward, the hotel was incredible. The Art Hotel is a renovated building along a tightly-packed block (like most) in a nice section of Buenos Aries. Use cabs in BA, since the subway is old. It's the oldest in the southern hemisphere. There are little lamps on sconces along the interior, and the windows are full-open. Kinda fun, but so stinky and slow that a cab ride it worth it. You don't have to tip the cabbies much. It's just accepted as a way to get around.
Buenos Aries has all the mix of a city's nice, standard and poor areas. Depending on your frame of reference, the poverty may be worse or equal to places here in the US. The tourist areas are typically interesting from a cultural perspective, and we managed to see 3 or 4 musuems, a famed cemetary, several city parks and monuments, and lots of shops and cafes. We talked about living there. It's that nice. Our perspective was severely limited though, since we didn't get outside the city proper. Next time.
Chile - now this was the majority of our trip. Chile appears as a bit poorer as a country, but it's undergoing a noticeable amount of change. Santiago is a bowl of smog, but the metro is brand new. Prices are slightly more expensive than the US, which surprised us a bit. Folks there were very friendly, from those we met and spoke to.
We took the metro to a downtown neighborood in Santigo, visited a local guiding service, and reserved a guide for a day of climbing outside the city. It was very fun, and we ended up spending the day with our guide for both the scheduled climbing, but also for lunch, and talking with her friends. The crag was similar to Smith Rock, OR, so we were comfortable. THe routes spanned the range, but we managed to keep up with anywhere she dropped the rope.
Other friends in Santiago held a BBQ, and the house was just spectacular. The cabbies in Santiago, from our experience are a bit more sneaky, taking you on winding routes or other tricks. We didn't use them as much, since the Metro was so easy, and the buses are very easy to take. The buses pick you up and drop you off wherever you want along the route! That was nice.
The car was a pugeot 207, which is a great little rally car. After Santiago, we headed to Picalemu, on the coast. This town was nice, but now outside the city, the typical level of poverty of towns hit us. Industrialization of most businesses is there, but the majority of the population doesn't live on that level. Instead, the family farm, shop or business is typical. This is quaint and appealing for a tour, but don't expect and flat line of quality across the areas, it's hit or miss.
After our jaunt along the coast, we found two hitchikers along Rt 5 heading South, like us. After picking them up and learning they were native Chileans also on an unplanned "trek", we agreed to link up and travel together. This was a great turn of events, since it made the trip much more colorful.
They translated spanish for us, and taught us all along car trips, which was awesome. We learned spanish faster than we expected (still at the level of about a 5 year-old). Especially nice was the ability to get some cheaper rates on places to stay by sending the native into the lobby first to negotiate the prices. We usually spent the difference by treating them to dinner. Everything worked out great.
Camping in the foothills of national park for Mt. Villarica, we found hot springs and great little hikes. The vistas were outstanding, but the roads were terrible. Several initial trips to somewhere make us all think "we are never getting back out on this road", but the little car managed to keep bumping along. The noises were scary, and i'm sure there's a few pieces still back on the road, but it ran and ran.
Look for more details in Part II
First, while in Buenos Aries outward, the hotel was incredible. The Art Hotel is a renovated building along a tightly-packed block (like most) in a nice section of Buenos Aries. Use cabs in BA, since the subway is old. It's the oldest in the southern hemisphere. There are little lamps on sconces along the interior, and the windows are full-open. Kinda fun, but so stinky and slow that a cab ride it worth it. You don't have to tip the cabbies much. It's just accepted as a way to get around.
Buenos Aries has all the mix of a city's nice, standard and poor areas. Depending on your frame of reference, the poverty may be worse or equal to places here in the US. The tourist areas are typically interesting from a cultural perspective, and we managed to see 3 or 4 musuems, a famed cemetary, several city parks and monuments, and lots of shops and cafes. We talked about living there. It's that nice. Our perspective was severely limited though, since we didn't get outside the city proper. Next time.
Chile - now this was the majority of our trip. Chile appears as a bit poorer as a country, but it's undergoing a noticeable amount of change. Santiago is a bowl of smog, but the metro is brand new. Prices are slightly more expensive than the US, which surprised us a bit. Folks there were very friendly, from those we met and spoke to.
We took the metro to a downtown neighborood in Santigo, visited a local guiding service, and reserved a guide for a day of climbing outside the city. It was very fun, and we ended up spending the day with our guide for both the scheduled climbing, but also for lunch, and talking with her friends. The crag was similar to Smith Rock, OR, so we were comfortable. THe routes spanned the range, but we managed to keep up with anywhere she dropped the rope.
Other friends in Santiago held a BBQ, and the house was just spectacular. The cabbies in Santiago, from our experience are a bit more sneaky, taking you on winding routes or other tricks. We didn't use them as much, since the Metro was so easy, and the buses are very easy to take. The buses pick you up and drop you off wherever you want along the route! That was nice.
The car was a pugeot 207, which is a great little rally car. After Santiago, we headed to Picalemu, on the coast. This town was nice, but now outside the city, the typical level of poverty of towns hit us. Industrialization of most businesses is there, but the majority of the population doesn't live on that level. Instead, the family farm, shop or business is typical. This is quaint and appealing for a tour, but don't expect and flat line of quality across the areas, it's hit or miss.
After our jaunt along the coast, we found two hitchikers along Rt 5 heading South, like us. After picking them up and learning they were native Chileans also on an unplanned "trek", we agreed to link up and travel together. This was a great turn of events, since it made the trip much more colorful.
They translated spanish for us, and taught us all along car trips, which was awesome. We learned spanish faster than we expected (still at the level of about a 5 year-old). Especially nice was the ability to get some cheaper rates on places to stay by sending the native into the lobby first to negotiate the prices. We usually spent the difference by treating them to dinner. Everything worked out great.
Camping in the foothills of national park for Mt. Villarica, we found hot springs and great little hikes. The vistas were outstanding, but the roads were terrible. Several initial trips to somewhere make us all think "we are never getting back out on this road", but the little car managed to keep bumping along. The noises were scary, and i'm sure there's a few pieces still back on the road, but it ran and ran.
Look for more details in Part II
Tuesday, January 17, 2006
Progression
There's an interesting effect in a reltionship. Familiarity. As two people spent more and more time together, working through both their individual demons and the friction of a life shared, a peace arrives.
I speak autobiographically of course. The Portland, OR winter has been a soggy one, with jaunts outside fewer than in recent years. We've also taken on a large number of indoor projects. After publishing our first game, deploying a rather nice art display, managing some remodelling and constructing a bouldering wall in the basement, there's been tons of time with a roof over our head.
All of these projects were collaborative, which is how I've arrived at this topic. After the "interesting" moments in a relationship that present new facets of a person's character, the finite set of these moods are exhausted and then one learns to navigate them. I don't believe this is any profound discovery, but one that requires more time and effort than many folks put into their relationship - even after any number of other milestones (dating, living together, marriage, etc).
A friend of mine once said that before commenting on any relationship, "wait until you're somewhat trapped together and utterly bored." Well, that's one metric that I feel this season is presenting. I'm happy to discover that it seems such moments won't be a dry spell for creativity. In fact, we may be more productive than when the sun steals us away to frolic aimlessly.
Even so, I'm excited to abandon winter for a month and head to South America. After my recent lightning-fast mastery of snowboarding, due of course to my wonderful coach, just touring around sounds perfect. Also, a constant flubbering of spanish should be great fun!
J
I speak autobiographically of course. The Portland, OR winter has been a soggy one, with jaunts outside fewer than in recent years. We've also taken on a large number of indoor projects. After publishing our first game, deploying a rather nice art display, managing some remodelling and constructing a bouldering wall in the basement, there's been tons of time with a roof over our head.
All of these projects were collaborative, which is how I've arrived at this topic. After the "interesting" moments in a relationship that present new facets of a person's character, the finite set of these moods are exhausted and then one learns to navigate them. I don't believe this is any profound discovery, but one that requires more time and effort than many folks put into their relationship - even after any number of other milestones (dating, living together, marriage, etc).
A friend of mine once said that before commenting on any relationship, "wait until you're somewhat trapped together and utterly bored." Well, that's one metric that I feel this season is presenting. I'm happy to discover that it seems such moments won't be a dry spell for creativity. In fact, we may be more productive than when the sun steals us away to frolic aimlessly.
Even so, I'm excited to abandon winter for a month and head to South America. After my recent lightning-fast mastery of snowboarding, due of course to my wonderful coach, just touring around sounds perfect. Also, a constant flubbering of spanish should be great fun!
J
Subscribe to:
Posts (Atom)