A Person, Artist, Software Engineer, Geologist.

I'm an old timer in Rock climbing.  Not the Faux climbing in the gym but on real rock with whatever surface erosion has provided for it.  I remember a boulder problem on Mt. Woodson that was called Television Screen (aka, Super Edge).  It was a big rectangular block that was tilted just off vertical with an irregular surface and this wonder edge that also had variations in it.  There was just enough of both to provide light hand and food holds to lie back off of while edging with your feet on the face.  It was rated 5.10 and just on the edge of what I could do with my new (then) EB climbing shoes. I was so proud of finally being able to climb it with my new EB shoes.  Then a friend of mine just scurried up in the running shoes!  I could not believe it, regular shoes and much less effort! The difference between the two of us was the context, me -vs- him.  I could do it but I needed better shoes and it was still hard.  He just needed to try. The same is true of software

Life is not static so you have to mix it up a bit to keep it interesting.  Well that is what I've done (at least I try to do) with publishing an iBook using iTunes and the iBookAuthor software.  Nothing better than using a new tool and learning about a new field.  My wife is a writer so I wanted to get a little taste of publishing my self, but I'll never be in her league. A lay persons guide into the messy world of software creation. This provides a basic foundation of what software is and the basic forces in it development.  This should provide the reader with the general development process and the complexities that can arise in the phases of development. Free download of iBook here I wanted to lay a foundation of the messy (dare I say wacky) world of software development.  It sounds so high-tech and science like, but for the most part it's the interaction between people, each with there own issues, desires and feelings that are the primary factors in how software

Lately there have been a number of posts on Slashdot.org  about older (40+) software developers or the half life of software developers. I don't use the term software engineers because the majority of younger workers in the software field have not yet gain enough experience and wisdom to be able to consistently and predictable design, plan and implement complex software project without a lot of re-design and refactoring along the way.   Being a bridge engineer does not afford the re-building of a bridge 2 or more times before getting it right.  The same principal also applies to software engineers. Back to the Slashdot articles.  My though on the comments of the half life of software developers only be 15 years is what the company is using their staff for.  If you are interesting in keeping wages down, have only simple to moderately complex projects, use 100's of staff (in this case 4,500) and expect them to not have a life outside of work, then yes, the half life would b

I'm Lazy. I don't want to write more code than I need to. I don't want to create a design that is too complex. I don't want to write "the next big thing", I just want to get the project done and make it a success. More code = more complexity = more debugging = more testing Even though I'll create bugs, I want them to be easy to fix, so I architect the design for each correction.  I don't want to be asked questions from other engineers on how things work so I make sure the class names, object hierarchy is clean and the operational processes are simple to understand. I don't want to have to hunt all over the code for related behavior so I group them by name or packages. I don't want to have to work late so I under promise and over deliver. I don't want to be confused so I ask stupid questions so that even I can understand what I need to do. I don't get too involved with shiny new objects because 1) too shiny and they distra

I've been revisiting HTML5 developing of late.  What I've found is three broad categories (I group by nature and habit), of current HTML5 development methods. They are: The tried and true, create your HTML page, add JavaScript and sprinkle with CSS.   Use "heavy weight" framework like Sencha's Ext-JS.  Heavy weight in sense of complexity and understanding.  Even for me it's a bit over whelming. Find a middle ground method that is in between the "build everything from the ground up" approach and the "kitchen sink" toolkits and libraries. I think I have found my "porridge that's just right" development method in the form of Enyo.js.  This is the framework that was born out of WebOS and is now in it's 2.0 release.  It's refreshing not to work in an all too common 0.999 release of a project and with the simplicity and clarity of design and implementation that eludes a project like Sencha EXT-JS. The Enyo.js co

Just read the book "Team Geek"  (amazon)  today and I would highly suggest reading it.  It's short, to the point and covers almost all aspects of development teams and the issues therein. It's a great book.  It does not mince words on problem staff, management (good and bad) and the multitude of issues that we have all been exposed to in our careers.   The good and the bad. Where Buddhism is about understanding oneself and making changes based on this understanding, this book covers the other side of the coin, working with others, problem staff, management anti-patterns and culture.  I can't say enough good about this book. The only comment I do have is the section on the physical working environment.  There are workgroups on one end and offices on the other.  I understand the flow of communication with workgroups but the interruption and lack of a personal workspace can effect a number of people.  This is somewhat covered by the common use of headphones (

Last months news that Facebook was re-writing their iOS application did not come as a surprise.  I had been following (and researching) the trend of using HTML5 for native applications.  It appears there is a much larger population of web -vs- iOS developments and the lure of using what you know to solve a new problem is very temping.  It's this whole "change is hard" thinking. Facebook knows web development (PHP, JS, CSS, etc) and its understandable that the HTML5 option would be on the table.  It's not for a lack of money or resources.  I believe it was the thinking that there customers are familiar with the desktop browser version of Facebook and thus the transition for their customers would be a minor issue.  Business win, developer win, customer win. Except, for two issues: Their mobile users may not be the same as their desktop users, thus different expectations. The expectations from a mobile application (i.e., native) are much different from a mobile b

There are so many catch phrases used in our (every) profession that are accepted as truth, that I would explore a couple of them. They are: - Re-writes never work. - Fast, Easy, Quick.  Pick 2. These phrases are used more to support a preexisting position of the programming staff than reflecting any real truth.  They are tools of propaganda and mis-information that are pulled out once in a while to guide decisions to a pre-determined goal. While experience may have proved these statements to be to true, they must be looked at in context and the amount to sampling to achieve these so called truths. For those only having 5-10 years of programming experience behind them, the occurrences of major re-writes and FEQ (Fast, Easy, Quick) decisions may be limited.   Re-writes of a major product are not that frequent or a product would never get released and provide the business with time to recoup it's investment.  Likewise with the repercussions of FEQ decisions where monito

In software development, we struggle with our own thoughts for the directions we take.  Strive for the shiny new object to develop with?  Use our current tools or take a risk on a newly released tools for new project?  What is real and what is driven by our desires and personal wants. We like to think that we make rational decisions but we don't.  We fool ourselves by pretending contraary evidence does not exist or apply for the decisions we make. This can get us in to big trouble. This is not limited to indivuals but to companies as well.   Google has been denying that fragmentation is a problem with the Android ecosystem.  That what worked for the phones would work for tablets (it doesn't).  Adding fragments that require even more resources, id, files and references should work fine for larger screen sizes (it doesn't).  Tablets are just like phones except we can just place more of the same existing views on the screen at the same time, it will work fine (it doesn&#

For me, its the year of change.  There have been so many changes that have occurred this year that I have embraced them and am planning for more. Besides the changes in my life, I'm continously looking for changes that occur in the world around me and here are a couple of my observations.  Of course they are only my opinion but it's food for though never the less. It's the human (or so we would like to think) touch.  Apple's release of Siri and the enabling of using ones voice for information and operations has met with praise and imitators.   People criticize it for not being perfect, for it's limitations and quickly released voice assistants of their own.  But the point of Siri has been lost on many.  Siri is not about just providing another method of interfacing with a computer, but instead Siri is about trying to bypass the computer and providing human qualities in interaction with the user.  It's not about executing commands, starting applications and

Back from vacation and got some great photos when we where at Wakulla Springs State Park (in Florida) for a day.  This is the worlds 4th largest spring and it creates a new river where it comes to the surface.  It's a great road trip destination. Some interesting photos from Wakulla Springs.  The first is the mens bathroom.  It's a little lesson in design for urinals.  While the urinals do fit in this location, the users (when all are occupied) do not.  Given the increasing girth of users these days, the position that the users would be required to take are, a little too close for personal space.  This would be a user design fail in my book. About the springs themselves is that they harbor a great diversity of wildlife including alligators, turtles, birds, deer and snakes (water and land).  Did I mention alligators?  There is a very reasonable boat ride down an up the river that is created by the springs.  Well worth the $8 dollar cost. At the head of the springs is a

OK, there are not that many old time software engineers, but there should be.  Just finished the book "To Forgive Design" which is about engineering failures (of the bridge, crane, boat kind) and what engineers should and do learn from them.  The last chapter is one of the most interesting and also applies to software development. Engineering is thousands of years old and there are still failures.  Software development is only a few decades old and is somewhat still in it's free wheeling days, but generally people don't die when software fails (but there have been some cases). The bar is so low and the turnover so high that valuable lessons are lost every "software" generation (10-20 years?).  Mature (HR speak for expensive) engineers do cost more that less senior developers, but the old mistakes are re-made, the desire to push though a bad design still exists and this costs $$$. If you have worked in this profession for any length of time you may ha

Starting a new project brings waves of emotions as I ebb and flow from optimism to pessimism and back.  I await for first growth in the code base until I feel firm in the direction and progress.  The general scope has been made but the details, oh the details.  They lay around like building a house from Ikea parts.  They are all small and minor by themselves but they all have to be put together in to a form where the project breaths to life in a not-too-scarry form, waiting to be prettied up later. With each new project is the opportunity to learn some bit of new technology that I've not used before.  Coming from decades of professional experience I get to look at the new technology, little impacted by the hype and blessings that may be heaped on it by numerous web pages and developers.  What I find is what can this technology do for my project knowing that jettisoning it is always an option for my 2nd or 3rd choices. Never get too burdened down with non-core technology, I'

Just ordered a book titled "To Forgive Design: Understanding Failure" by Henry Petroski.  It's about engineering projects that where designed to standards of the day but still failed.  It's a part of history that intrigues me.  From the Great Eastern ship to the Tacoma Narrows Bridge, there are projects that where designed and planned based on the best standards of the day, but they failed to understand when the standards or times have changes. Skip ahead to the current Post-PC period. The form factor, operating system, language, uses and manufactures have all changed.  Try to stuff a PC into a netbook or tablet does not work.  You can do it and get some sales but the market has moved forward without the a lot of the features that we thought we needed. The enterprise apps, the expansion slots, the same old apps, all being depracated in the post-PC period. Looking forward to reading the book and gaining insight from history.

Bald Eagle on the side of the road Sometimes it's nice just being and not doing programming, watching new, whatever.  Last weekend my wife and I did a short trip to Capital Reef National Park.  It's a small park and this time of year it's basically empty except for the odd bus load of German tourists. No programming, thinking or doing, just being. Here are some of the photos during the trips.  Saw some big horn sheep on the trail, the bald eagle on the side of the road and the signs of a small town and a slower life.  It was a nice break. Got in 2 hikes in two days with the longer one starting at the campground (about 8 miles, out-n-back). This is for the pickle lovers out there.  For me, not so much. Just an old store front that caught my eye with the faded green awning and the bright green 7-up machine on the end.  I just found it interesting. Just another old garage with a matching pump.  Not sure if the colors that interested me, the

Words are simple, short and yet can evoke so many emotions. Case in point (from the way back files) :  The words "Won't Fix".  This originated from a QA engineer that has created an issue for modification to how a feature operated.  Fair enough.  The request was talked about and decided that this modification would not be implemented.  The issue was closed with the QA engineer using the words, "Won't Fix". Simple words but they express much about the perception of the QA engineer.  "Won't Fix" seems to indicate that 1) the feature is broken and 2) the development engineer is ignoring a known error.  Of course the perception from development engineer may have been that 1) the feature operates as expected and 2) making the suggested change would not be beneficial to the product. So much in a simple word. So how simple can a word be and still contain so much subjectivity and emotion behind it? "Hacked" - That code is "hack

Lately there has been a call by governments to teach computer programming to more students and at an earlier age.  This is coming from both the UK and the US and I can understand this concern with an emerging workforce lacking the skills required to compete with it's business demands. I understand this goal, as you always want the most educated and creative population as possible.  Knowledge is always beneficial to individuals,  communities and countries.  Every student will not have the aptitude for programming, but it should not be scary to them either. Teaching software development is not the same as a trade school with the goal of lesson drills and testing for repeating those lessons.  As with any good education the ability to understand and apply what has been learned in new conditions and solve problems is the real goal. Teaching 1 million Visual Basic programmers would not go far to increasing our technology workforce. Teaching 1 million knowledgable creative, understa

The Susan G. Komen "Stomp for the Cure" was last weekend.  I've been doing this event for about the last 8 years as it covers both my love for snowshoeing and supporting breast cancer research.  But this year has been different with the fiasco of Komen cutting off and then restoring funding of Planned Parenthood, in what was viewed as a very political move by some of it's leadership. What does this have to do with Software.  Well it's about how an organization can confuse it's mission for it's self.  There was no confusion for their donors, the mission was women's health and not the Komen foundation.  The talk at the snowshoe was all about how they would not have participated if the funding was not restored, with many still very ticked off at Komen. Back to software.  I suspect this is the same thing that happened to Microsoft in the mobile market.  They used to own the smartphone segment and being Microsoft, it appears they expected the market and

Yes, I have an iMac and iPad at home but I work in a world of Windows and Linux.  Apple for me is not a religion but opportunity.  Not in the monetary sort of way but in mental or opening up of ideas and thoughts. I've lived with the grey windowing boxes for so long following the needs of the enterprise that nothing seemed to really change.  Faster processors, bloated software and frankly the same terrible UI that me and everyone developed.  Yuck.  The web has helped open up the options but it was still confined to the philosophy of mouse and menus.  Even the new Ribbon toolbars in Office is a feeble attempt to break out of the same tired UI that has trapped us all.  This tells you just how stuck MS thinking is.  It's changing of late but I'm not convinced they can make their vision stick. Event the news this week of Android royalty telling developers to ditch the menu button in their apps is another nail in the coffin of old UI's. Apple has open the door to not o

I've been going thought a learning phase this year.  There have been so many new (at least to me) tools and products that finding time to research them and deciding if should spend my precious time on using them is a challenge. What I'm looking at now.... iBook Author.  I'm currently (slowly) working on an eBook project and I'm using Pages as my writing tool because 1) I already have it and know it and 2) it can export directly to the ePub format. Now Apple comes along and creates their TextBook format along with the iBook Author tool which uses their own extensions.  The draw for me is the media inclusion in the book of dynamic content.  The map images, photos and videos are simple and know content types.  What caught my eye was the HTML content is in the form of DashCode apps / widgets.  This had led me down a different trail of finding out more about DashCode as it's dual use for iBook 2 and Safari mobile apps.  I always like it when I can double my use for

Happiness comes from within.  When creating software for a living there are many times that I would rather be coding in a different language, designing a different app or at home with my slippers on an a Hot cocoa when working on my computer.  But most of the time I'm not.  I get paid for creating programs that others need, in the language that the project requires and in a place that is not my home. So how can I stay happy?  Well, first I get paid, but more than that, they appreciate what I can provide for them and this provides me with much happiness.  This takes me a long way, but not all the way all of the time. I need variety, new knowledge and something I can call my own.  For software developers, our applications, our code has a limited lifespan.  Sometimes we will work on a project and it's never used.  We will have worked on a project for months or even a year and it's thrown away.   Other times our code lives for a few years, to be replaced when needs change o

Just got back from a trip to the northern California Coast area, Guerneville to be exact, and ran into some folk art (on purpose) by the artist of Partick Amiot in Sebastopal.  This is one of his pieces on the right.  Very cool to see out in a yard.  I then ran into another piece of somewhat practical (unintentional) folk art on a walk (see below).  What a hoot to see something that was created for a practical purpose (lighting and holding up the mail box), but could also be placed as folk art.  This made my day.  I was just imagining what the owner was thinking when they put this together. Seeing this I of course got thinking if this somehow equates to software and it's development. OK, lets compare the creation of folk art and software. If you have two different software groups create an application with only vague design or requirements, how different would the resulting applications be? How much of of the developers personality and perceptions be projected into the code,