A Buddhist Software Engineer

Words (they are really all we have)

2012-02-25T14:21:00.002-07:00

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 "hacked" together.
"Best Practice" - My solution is the "Best Practice".
"Buggy" - That code is "Buggy".

These words tend to shutdown and prevent discussion of the issue at hand, as they try to promote a position as fact to direct a conversation in a specific direction (per the speaker). In some cases the above statements may be true, but they are also overused by developers to promote a specific (and many times very subject) viewpoint.

Words are tied to emotions and beliefs, with even the use of very simple words exposing the human behind the conversation. It's not that some engineers do this, it's that all humans do this. The trick is to accept that we do this and work to both minimize this behavior in ourselves and work around this when it comes from others.

The Call to Teaching Programming

2012-02-19T17:13:00.002-07:00

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, understanding programmers would. The goal is true but the difficulty is in the implementation. With the focus on the mechanical logic, testing and measuring results, I'm not sure this will get very far. First of all I'm not sure we really know how to teach software development. We have the languages, the lessons, it just feels that there is so much that we are missing.

I tend to think of creating software is a mixture of logic, knowledge, emotions and physiology with so much not being explored on how human goals effect development. With the web filled with technology knowledge of how to program with specifics on every possible behavior and operation, what is there to teach? Well, the web is filled with information, but it needs to be placed in the context of human lives and the dynamic interaction of a complete development project. These web islands need to combine into a complete and integrated world that the students can navigate through. Thats what we could teach.

(Do you know what the photo is of?)

Breast Cancer & Software

2012-02-12T11:19:00.001-07:00

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 developers to stay with Microsoft. They didn't. The iPhone was easier to use, beautiful and provided a larger benefit to users. When the developer tools were released developers flocked to create apps for it. Even though developers needed to learn a new language, libraries and framework (Objective-C, Cocoa, etc) they flocked to it. Microsoft mobile fortunes dried up.

What was Microsoft's mission in mobile? It appeared to be "because we are Microsoft" which does not mean a lot to consumers or developers. Apple's mission appears to make products that are easy to use and beautiful to look at and hold. Beauty evokes is a strong emotional response, you don't see may weeds in vases for valentines day.

So what is Google's mission statement. Surely it must be more than "not Apple and not Microsoft". And RIM? They used to be enterprise security and communications, but that appears to be not enough anymore.

What Apple Means To Me

2012-02-05T11:20:00.001-07:00

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 only touch UI's but what it means for a personal computer. You hold it in your hand, you use your hand (and voice) to interact with it and it does not run Office. If Office is released on the iPad it will sale tons, but Office is an application of the old guard enterprise and the iPad is personal. This is not just a different form factor that contains the same business software, it has nothing to do with the enterprise and that confuses the old guard.

It's always been going in this direction. From main frames, to desktops, to laptops to phones, except Apple decided to ignore business and skip getting businesses (aka IT's) permission and cut to the chase. People where so confused by what the iPad was for, when just holding it you hands would tell you. It's yours alone to do what ever you want.

Even Google has a problem with this whole notion. What the heck is Chrome OS for? It's not personal as you can't use it anywhere (try standing up and use it) and it's appears still tied to working with business and IT. In fact the whole notion of providing Office type applications is, well still old guard thinking. People are not businesses, they need different tools in their life.

To me apple provides me with an opportunity to explore the tech world unshackled by IT and the past.

Research and The Cycle of Life and Death

2012-01-27T15:24:00.001-07:00

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 knowledge I've gained. My first book project would be free so the license issues with iBook 2 would not prevent me from distributing the book to other ebook distributers. There may be a iOS customer that could benefit from a lightweight (quick / cheap) DashCode mobile app. This is on going study.

My other research area are for REST WebServices that are lightweight. I've used many implementations of these but I've seen a couple of articles on Node.js so I did a wee bit of research on this. My first contact with Node.js articles stated it was "the next Ruby On Rails", which really turned me off. When ROR first appeared on the radar ROR was really hyped up. So much so that it's claims almost extended to brining back the dead. It took a few years but the hype has been gone and ROR saw it's peak years ago with almost no press today. It could never live up to it's expectations and other shinny objects drew attention of early adopters. Back to Node.js.

Right now I do not feel that I'll continue my research on Node.js. It feels like a solution in search of a problem with it's main attraction being the use of JavaScript on both the client and the server. It's not that I'm against running JavaScript on the server, I'm not, but 1) JavaScript was not designed for the server in the first place and 2) Node.js touts it's own webServer for Node.js operation.

Just like ROR had it's own WebServer so does Node.js, and these should be used instead of Apache or JBoss that are scaleable, secure, mature and documented? Yeah, so we wrap the Node.js server under Apache, then we have increased the complexity a bit. Then there are no dev/debugging tools for this yet (yeah you can alway patch something together, but you get my point). ROR spent years trying to convince everyone that it could scale with every release being so much better. Now Node.js is claiming it can scale with it's lightweight processes. Most of the information does state that Node.js is best for a specific usage of short WS requests (and they do state this which is great), but please don't compare it to ROR and follow in it's mistakes.

Node.js will not make it past my research phase. It's tools are too immature (I'm not that early of an adopter) and I'll not sure that it will make it out of the early adopter usage.

I don't know if DashCode will gain wide adoption. The IDE for it has not been updated for a couple of years but it may find life in a different form (iBooks). As for Node.js, I'll wait and see. ROR rocketed so high and burned out, not unlike a number of technologies in the past (Wicket, AOP anyone?), so may Node.js. The lifecycle of technology is not unlike those of introduced species, some fill a niche and some don't make it.

It's life, just in a different form.

Striving to be Happy

2012-01-08T11:44:00.000-07:00

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 or it gets re-written. We never really get the sense of benefits to the users. We can feel out of touch. I'm sure most users would never even think of the lives of the developers that created their applications (except when there are bugs) and what they put into it.

So what are we to do? We do nothing. We change jobs. We slow down at work. We try to change the language we use at work. We try to change the process we use at work. We get depressed. We yell at others. We do all sorts of things, that from an outside perspective, are not beneficial to us or others around us.

There is no one right answer to making yourself happy, but each person needs to look at themselves and ask themselves what would make them happy. This can take lots of time, but it's only something that you can answer.

Forcing others to switch languages or process to make you happy should not be high on the list. You would not want others telling you what to do to make them happy, so why should you?

Changing jobs may work, if (make sure it's the right if), this is truly what will make you happy and not just a pattern of change. I've been in positions where it appears the company is really working hard to make their employees un-happy.

Slowing down and doing less (or worse) at work may be a self fulling prophecy, so you feel you have to leave. It's hard to see how that would make anyone happy.

It can be hard not to strike out at others when your not happy. But understand that this is a sympton and not a cure.

I'm still striving on what makes me happy. I work on it all the time. I find that focusing on small accomplishments are a big win. I have a number of side projects going on that are not meant to bring in much value other that to make me happy. Some I know I will never finish, others may only take one hour, but they make me happy and that suites me fine.

At work I find pleasure in finishing some aspect of what I'm working on. It could be a design, a feature, a bug or talking with a co-worker and understanding how something works (talking to others is under rated). It's the small things for me. I don't worry too much about the bigger issues as they tend to get smaller as I attend to the smaller aspects.

In the end, I find I can be happy with small aspects of life. If I look at all that is going around the world, then that is when I get over whelmed with it all.

Is Software Folk Art?

2012-01-02T12:01:00.002-07:00

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, language, operation, UI, features, stability, etc?
How maintainable would the code be? (Seeing as most of a projects life is spent in maintaining, would this be a concern?)
Would the different teams refer to their work as "Engineering" and how would they justify this?
At the completion of the applications (or after a set period of time), what would prospective buyers (customers) pay for the applications and what would their comments be?
How do you build a business on developing software like this? and getting customers to pay big money for it?

I love folk art. I get a different view of the world and my take on it. I even like Folk software development once in a while and the freedom and creativity it brings.

However there is the time and place for folk art and not every business can support it. For the times when detail designs, requirements, timetables and expected results must be attained, folk software development may not be the best choice.

But the world needs both.

Causing Myself Pain

2011-12-20T20:05:00.001-07:00

The basic beliefs of Buddhism is that there is much suffering in life and much of the suffering is self inflicted. There are many things that have caused me pain and strife in my life, but I really work on not adding to the amount of strife that I'll already endure. My developing software is always a source of self-induced strife and I look for reducing my self punishment as much as possible.

If you have been in this business a long time then you have been approached by friends or associates to create some software for free. It's a hard choice sometimes, but the best answer maybe 'no'. Software takes time, the lifecycle is long (how long to maintain?) and it can distract time from your family and happiness.

Does this apply to companies as well? I would think so. Let me explain what I see is currently occurring in mobile developement.

Knowing both iOS and Android development, I've noticed a divergence of benefit to the developers and to the respective companies. iOS is only on two form factors (iPhone and iPad). Android is on a range of form factors from 3" to 10" and above, each with varying screen ratios. For the most part, the general development was the same.

You could handle the UI controls and layout in code (lowest level), create views for each screen on a screen (controller / activity) by screen basis. So far these have been the same for both platforms.

For iOS you had the option of having two different views (nib files) for each controller, one for iPhone and one for iPad. The different views could both access the same (or different) controllers for sharing code. Almost all UI could be created using the Interface Builder which is a big help. The down side was IB had a learning curve that can throw developers off the iOS platform.

For Android you basically had multiple layouts possible for each activity. This was basically the same as iOS. The main difference was that most everything with the layout was hand rolled XML with references to other XML files and resources. Lots of references and Ids to keep track of. Yes there is a UI Builder but they could use a lot of work, so I've found it's just easier to edit the layouts by hand.

Now the divergence..

Android did not handle tablets, so a new pattern was added to the mix of Activities and Layouts. These are the Fragment classes. This will work but adds to the burden of the developer and increases the complexity and permutation of activities, layouts and now fragments to try to provide workable solutions for the wide range of form factors. All this while not providing any additional tools to handle this added complexity. It's still all XML, references and resources basically by hand. So as a developer do you make a decision that all forms from 3"-7" get the phone version and the 8"+ get the tablet version, or do you try to create layouts and fragments for even more sizes to provide better screen usage? It's not looking good.

iOS on the other hand has made life easier for developers. You can still create nib files for each controller, but the preferred method is now the storyboard. Instead of multiple nib files there is now a single storyboard file for each form factor. It contains all the views, controls, segues and transitions for all the views for the complete app. This is all laid out in a single screen in Xcode for the developer to work with and provide a single screen view of the complete app. Navigation, Tab, SplitView, Modal and others UI patterns are all supported. Each view within the storyboard can then be assigned to a specific Controller with the UI controls wired up to controllers objects. For a universal app there would be one storyboard for iPhone and one for iPad, each showing the complete workflow and operation and without any code, xml, references or Ids. Apple has provided a solution that has reduced the complexity of the code and made it easier for the developer while still providing an optimal solution for the user.

Apple appears to be limiting choice, with benefits to its developers, users (better apps) and themselves, where they can continue to move forward with tools and platform without too much technical debt.

Google appears to be heading in the opposite direction. With the possible permutations from all the different form factors, increased complexity of the Activity/Fragment/Layout pattern, along with developed less likely to provide solutions for all options, a case could be made that Google is hurting themselves, their developers and users.

Which path reduces my future pain?

Sybil and The State of Computers

2011-12-15T19:26:00.000-07:00

I just finished reading "Sybil Exposed" which I found fascinating on multiple levels. On one side it was about how much a single person can influence a profession (for better or in this case for worse) and how the progression of the Psychotherapy field, evolved over time, with some truly bazaar concepts and methodology.

This evoloution is not unique to this field but I'm using it to illustrate my points.

At any moment in time, the actions, concepts and beliefs for any field may appear to be correct and normal. But when viewed in hindsight many years later, can be seen for what they are, bazaar and narrow minded.

The concepts of Freud with the fixation on parenting and sex. The use of drugs and hyponosis induced states to reveal memorys that never existed, was a common and accepted practiced. Some viewed this as normal, but not now. Today we know the detrimental effects of these therapies had and would not dare to revert back to those practices. We've changed and learned.

Flash forward to today with software and computers. The notion of going into a room or a desk where the computer is located, appears normal. Likewise the need for a physical keyboard and mouse to act as a intermediary to interfacing with the computer, is normal.

When the iPad was released I was one of the first in line. I did not know where this was going to head up but I knew that it was the start of a big change in computers. Plenty of nay sayers. Plenty of fad callers. But think about it as if you where from the future. Why would "you" have to go to the computer, why don't you just take it with you? Why do we have to work in "cubes"? Because that is where the phone and computer are? Yeah, right.

Now the nay sayers state that tablets are great at consuming content but not for production. To that I say wait. Tablets will keep chipping away at desktops until the majority are not desktops. Apple has already done this years ago in their stores. So how many other businesses really need a desktop?

I can't think of any applications that I've written...ever...that could not be used on a tablet or phone with providing greater benefit to the user in the process.

Security may be an issue with tablets and mobile devices (both for mobility and networking) but security is being forced to change how they view these devices. You can't stop progress, but the nay sayers would like to.

Multi-Tasking (in Android & iOS)

2011-12-04T13:37:00.002-07:00

This post is not about how-to perform multi-tasking for Android and iOS, it's about my thinking related to how I handle threading issues in Android and iOS.

I've written multi-threading code for decades (in C/C++ and Java) before I got into mobile development. Threading was one of those issues that used to be a black art. You needed to handle and understand all of the semaphores, mutating and memory issues to provide a robust threaded application. It's a lot easier now in both Android and iOS. Clear examples and simplified code make threading quick and easy, but there is still complexity underlying the concept of threading for the UI.

My biggest insight when switching to mobile threads is the pattern of placing the threading inside of the activity or controller. This is a big plus for simplicity and ease of use for development. The thread is right there where it's needed and the thread has access to the Activities (or Controller's) data members for updating the UI when it's safe. Cool, very cool. Nice, neat and local to it's usage. Threading for the masses.

For most of my threading issues this is what I use. But this local pattern is not suited for all needs and is where the patterns for Android and iOS diverge.

One of my biggest issues with Android is the destruction of the Activity on rotation. Not a big deal when doing Android phone development where the user is primary expected to to use a single orientation, but tablets are more rotatable. The screen ratio is closer to not have a single preference and different uses prefer different orientation (books -vs- movies, etc.). With such a large screen to present on, it's expected that the tablets will be rotated and the app should support it and this has an impact on threading in Android.

The pattern of having the thread local in the Activity is great except when the device is rotated, the app supports it and a local Activity thread is running. The thread will still be running, but the local UI data members that need to be updated will be for the pre-rotated Activities. In short, it will not work in all cases, it's one of those timing things, sometimes it will work, sometimes it won't. The local pattern will fail as it's too tightly coupled to that instance of the Activity. For this case the thread needs to be changed to couple loosely to the Activity when updates need to occur. I'm not going to cover solutions for this (they are not very hard, just different, i.e., observer pattern) but to express my thoughts of the Android threading for Tablet applications that should be rotatable.

I view the ability of tablet apps to support rotation as important as it impacts the tablet's usage. Don't force the user to rotate the tablet when switching from reading a book to going to the App marketplace.

On iOS the threading issues for local threads inside of a Controller as much the same as Android except when the device is rotated there is no destruction of class instances and the same local thread pattern will always work. The local threading block still has access to the controllers data members for updates on completion on the Event thread. In iOS GCD (Grand Central Dispatch) the level of control other the threads is also much greater. The queue's that can be used used, the processing order (serial or parallel) allows control that does not exist (easily) in Android. I'll be using mostly the local pattern for my threads in iOS. This is switch from my non-mobile apps where the threaded tasks are contained in their own class and packages.

My bottom line is that I've switched the location and implementation of my threads to use the local pattern of placing the threads inside of the Activity and Controllers. It's just too nice of a pattern to miss out on. My exceptions are for 1) Android apps that are rotatable and 2) longer running threads that impact multiple Activities or Controllers (I use MVC notifications for those).

It's been enjoyable working with threads for mobile apps and understanding the local pattern. It makes my life easier.

Self-Deception

2011-11-29T19:08:00.000-07:00

Yup, we all do it. I know when I do it. I feel bad about it because I'm tring to fool myself and that only makes me the fool.

This came out of reading an article in New Scientist (Oct 8th 2011 issue, page 32 if you still use print) about biologist Robert Trivers. Great interview that was right on (for me at least). He was not talking about programming, but you know how it applies. We are debugging a very difficult issue and we try to convince ourselves of what the cause is. Yeah, right. Facts are facts but that does not stop use from deceiving ourselves in so many ways. Convincing ourselves that a bug is really a cool feature. That we really know how the users will use the product. On and on and on it goes.

One of the most interesting points in the interview is even knowing that we are deceiving ourselves, we still go ahead and do it! Robert knows it and still does it! Life hard enough and then we do this to ourselves? Yuck.

The positive side to all of this is because we do know this, we can take action (abet after the fact) to correct ourselves. There is no shame in admitting we just lied to ourselves, tough yes, but come on, we can take it, it's us we are taking about.

See how many times this week you have tried to deceive yourself. Be honest. You don't have to tell anyone but yourself.

Fun With Android

2011-11-20T10:46:00.000-07:00

Been wanting to post about my perspectives on Android development. This is not a Android -vs- iOS blog but just what I see as my perspective of Android development.

Android feels easy. Java feels like a well broken in shoe that slip on in the morning and can wear all day, so Android development feels easy for me. I understand the attraction of the Intents and Activities for the providing of multiple filters for handling common features (select you email, photo editors, etc), but I view this as more of a benefit for geeks rather than most consumers. What kind of support is there for uses that download apps only to be presented with selecting providers for comment activities, only to want to revert to the built in provider (yeah you can clear the selection but they need to know where).

The destruction of the activity on rotation and on config changes feels like it's un-needed but exists because of legacy issues. The save/restore of activities values are simple but feel like it's best for simpler applications where limited amounts of data are shared / passed to Activities through Intents. It feels like the rotation feature was bolted on when it was introduced into Android (Android did not handle any rotation for multiple releases).

The roots of Android was for small devices and it's been expanded and grown to handle more complex applications and devices. To me this shows in the Intent / Activities pattern use though out Android. Small data, Activities and screens that worked well for small apps with low complexity but would would cause their own complexity if expanding for much richer and complex applications. A case is the Menu and Back buttons / actions. Yeah the buttons are gone in ICS, but the behavior still exists. I can see where these were of value in small devices (like the old Palm) and apps with there operation on the Activity stack, but with full featured applications in tablets, this may have limited use. The same for the data patterns of Intents as mostly the means of passing data to/from Activities. (This pattern is good for Activities outside of your applications scope, so it's more like an API in that usage). Internally in an app this pattern may be limiting with more complex data (updating multiple activities based on external data changes, async operations, etc.).

The fragmentation is a real issue with the slow rollout of updates from carriers, the multiple screen sizes and planning of base supported API's for my apps is a real concern.

The last issue is the simulator. It's badly in need of an update. The table version is so bad it drove me back to the phone version. Not good.

My bottom line on Android? I like it, it's fun and easy but some of Androids roots need to be considered in my applications designs so as not be limited by the Intents and data handling.

On the iOS front, I'll be going over the new iOS / Xcode 4.2 storyboard feature. Looks cool.

Bored?

2011-11-09T19:31:00.004-07:00

Saw a posting on Slashdot today about a programmer being bored at work and asking what to do about it.

Well, Slashdot readers being as they are, mostly responded with some not helpful suggestions (but some where). Seeing as I've been in the development field or such a long time and had my share of periods of boredom (and almost every other emotion) I thought that I add my response. Here goes.

The first thing to find out is what you are bored with. It may not be so easy to tell. Is it the same coding, no designing, no attention, lack of social interaction, gotten into a rut? It basically comes down to needing some kind of change. New job always comes to mind, but is that the easiest and riskiest method of forcing change on yourself, never mind that jobs may not be easy to come by. Change is needed but what and how?

For myself, I find I get bored if :

I'm not doing anything new
I'm not keeping myself busy (I love getting things completed).
I've run out of goals for myself

The first thing I do is, doing something different every day. It does not really matter what it is but it needs to be different. Different lunch, different web sites to visit, different clothes. Along with this I create a very simple ToDo list. Mind you it may only have one item on it, but it's something that I have not done before. It should be something of our my normal routine and can be accomplished in one sitting (so I can feel like I accomplished something). When I've done that one item, then add a new item and then maybe another. Starting making little goals to look forward to that do not involve your normal work.

Some of the things I have done to break up my daily patterns are:

Make pancakes (any cooking) in the morning instead of cereal.
Find some podcasts to listen to that is NOT on programming.
Go read a book (not a programing book) and reserve time to read it.
Do not listen to news.
Do not watch TV (or at least reduce it. No reality shows).
Go for a walk during lunch or when you get home (only about 15min worth).
Start a Blog (but be nice about it).
Have dinner with friends during the week.
Get another dog (but please don't go over 3).
Paint a room a strong color (no pastels please).
Read up on some aspect of history that you know nothing about.
Watch a TED video (ted.com).

All of these suggestions are to get you to change your mind set. It may be your job but first give changing your mindset first. It can be easier to change almost anything but your mind. People change jobs, locations and partners, all to avoid that it may be themselves that they need to change. All these little change suggestions are really just the seed of change that you can build upon and it will take time. Don't just change one thing and repeat, change, then change again and repeat.

Do something different, enjoy life more.

P.S. One thing to look out for is depression. Please search the web for information on depression and it's signs.

When is it Done?

2011-11-06T09:45:00.001-07:00

Words, they can be hard to come by, misleading (on purpose or mistake) and costly. The word "Done" means many things to different people during the software development process, with most of them not-really correct or helpful.

Software Engineer says "it's Done" - The code may have been written but not tested. Or written but not working, or done "except for some details", or if they told the client it's done, then what does that mean?
Project manager says "it's Done" - This depends on whom they are saying this to. Saying this to a client means that they should expect it in their hands NOW. If it's the CEO then it means, to appease, to inform, to CYA, etc.?
QA says it's "Done" - Then it means it's clear of bugs, ready to ship?

Done only means "Done" when the client has it in their hands, installed it and it works as promised. We have all seen or heard to people using the work "Done" to describe, what they perceive as their involvement, in the process of getting a product done. This word being heard or being used to the wrong person can lead to misleading information (at best) or mistrust (at not best). I'm sure the stories of shipping blank software to clients to meet a deadline of being done are true (I've seen this in the past). How is this helpful?

Lets view this from a more lethal point of view and replace the software development context with that of a surgery room and replay the statements.

The Surgeon was done with the procedure. Did the surgeon close up, did the staff count the supplies?
The hospital told the family that the doctor was done. What does this mean about the outcome?
The Post-Op recovery was done. Did the patient wake up? Is there a complication that will require follow up?

What does this mean for the patient? The patient only really cares that the everything is completed and there is a successful outcome (they can go on living).

All involved in the surgery can not and should not assume that because their direct involvement is over that there is a successful outcome. Only the end result will satisfy the "Done" statement.

So why is the implication, if not the actual word used so much in not the proper context? Because the same thoughts, fears and feelings are involved in everyone involved. The boss that does not accept "no" for an answer, the reward / penalty system linked to workers pay that encourages this to the desire to be accepted, impress, etc. There are a hundreds of ways to renforce behavior that is not beneifitial to others or ourselves.

(These can exists in cycles until the end)
------
Design
Development
QA
-------
Shipping
-------
Installed and Reviewed
Done!

Why No Code?

2011-11-01T19:23:00.000-06:00

There are tons of blogs that provide sample code on the web and I've found them so helpful to providing insight to answers I've been looking for. I would like to thank every one.

But my blog does not provide code. I've been tackling a different side of software development. The side that is filled not with code, but how we think about code, think about why we do what we do.

About source code. Sooooooo subjective. It's lifespan is limited to the development process and is soon turned into byte code by a compiler, never to be seen by anyone outside of development. Source code is like shared painting where everyone has a vision. The locations of brackets, spaces, names of functions, variable, etc. may instill heated debates from almost any group of developers.

My guidelines (only) for myself are:

Stay close to what ever standard your company uses. It's not that big of a deal.
Don't reformat others code. You would not want them to reformat yours and it really messes up version control duff's.
Don't enforce a strict format as it can lead to unwarranted confrontation (someone is bound to use a different format).
When working on others code and providing bug fixes, use their style.

You can tell by looking at source code if the engineer is competent and has interest in the issue. You can also tell if an engineer is not really "into" the issue at hand. Maybe they don't try to mesh with the style or operation being worked on. Maybe they provide a high rate of one-off solutions that degrade the stability of the feature. There are tons of issues with code that is written but for the most part, the only way to change code is written is by changing the way the developer thinks about it and that is a personal issue. People will do almost anything to avoid changing how they think.

For myself it's almost a daily if not hourly review of what I'm doing. My personal review contains simple thoughts like:

Coding in a non-harmfull way.
Seeing the code for what is really does (rather than what you want it to do).
Being mindful of that changes / additions that you do make. Thinking of others.

Just like in fixing bugs where you need to locate the root of the problem, writing code does not start with typing on the keyboard, it starts in your thoughts, desires, problems and hopes.

This is why I do not provide any code in this blog.

Software as Art

2011-10-24T21:13:00.000-06:00

When you work with developing UI code as much as I do, you run into the issue of UI as Art. It's (mostly) subjective. People have built up mental maps of their life, surroundings and how they expect life should be and why doesn't everyone think like I do?

I do it all the time, but now I try to seek out and enjoy the differences instead of working to avoid these conflicts of vision. Unless a UI design is specified before hand, I have to come up with a visual implementation that I feel suits the needs best. Sometimes it works, sometimes it doesn't. It kind of depends on who is playing the bills and what their vision of the issues are.

In this sense software is like art. Not just the UI elements, but the internal design and structure of software as well. Everyones internal bias get exposed when writing and looking at code. Different code may do the same thing but be completely different internally. Look at Android and iOS development, nothing a like but the end result is not all that different.

Now here is where it's painful to write software. Artist create art for themselves and are free to express their vision (except maybe commercial artists). Software developers are technical artists but are judged, praised, punished and rewarded on how they express or repress their own vision. This can be tough on a ego.

I wonder if this is a limiting factor in the professional lifespan of a software engineer?

Personal Anti-Patterns

2011-10-19T20:34:00.000-06:00

Software patterns are well know (Singleton, MVC, etc) as are anti-patterns (cut/pasting of code, etc.), but do developers ever think of their own personal patterns or anti-patterns?

Just as tool sets can vary from project to project and technology changes over time, personal patterns can turn to anti-patterns based on the project.

I know Java but I would not use Java on an iOS mobile device. The quality of the product would suffer vs using native tools. The same goes for trying to use Microsoft tools (does Mono come to mind?) on linux servers. But this is not about tools but about how you (as a developer) think about your role in development and how you personally effect it. If your pattern is thinking that Java is the perfect tool for any project, then that can become an anti-pattern if the project is on iOS.

The interaction between team members can also be effected by personal anti-patterns. Not asking questions is a personal anti-pattern, so is not making decisions or hiding errors. All behaviors that are not beneficial to you or your projects.

Take some time one of these days and just look at your self and see if you can spot any anti-patterns that you may have. Once you spot them (if you have any) see if you can not use them.

Not In Your Face (except this time)

2011-10-10T19:41:00.000-06:00

You may be asking yourself where are the Buddhist teachings in my posts? Well, I try to hide them in my topics but I don't want to be in your face as well. The reason for my posts are not to teach you how to be a Buddhist software engineer, but how I've faced software engineering. Which means facing myself, warts, insights, relationships and all.

Here is the "in your face" part: A good understanding of Buddhism can be found at Wikipedia.org to start with. There are so many books and web sites that you can explore that are only a Google away. The good step to understand Buddhism is The Four Noble Truths and I have found this to be so key to my life. Don't just read the Wikipedia page, please get a book by the Dala Lama on Amazon (or any of his books), read it and see how it relates to your life and maybe, to your philosophy of software development.

This is one of the questions I like to ask prospective new hires, "What is your philosophy on software development?". There is no right answer but it may provide insight into how the person will fit into your project.

Now to drift onward. I'll be in Nashville this next week at the Southern Festival of Books fair. I hope to return with some interesting photos and topics.

Why I Enjoy Working on U.I. Code

2011-10-08T14:32:00.001-06:00

I've worked in all aspects of code from libraries, DB design, Web/API-services, requirements and everything else, but I've happily fallen into being very strong in the design of User Interfaces. It's not that I'm artsy (I'm not) but I have a knack of being able to architect UI code so that the artsy presentation skin can be added easily without effecting the functionally of the UI.

Unlike other layers of an application / service (or whatever layer), there are discreet operations and parameters with expected results. Code can be written and tests created to the expected behavior. It's the same with DB operations but will a bit more complexity based on relationships, triggers and transactions.

Not so easy with UI code.

Write code to show a form, easy. Add validation and error handling and it gets a bit busier. Add related actions, operations, state tracking for enabling / visibility, mix with async operations for data streams and any gee-wiz widget behavior and it can get overwhelming. If these behaviors could be coded independently and then coupled together for final implementation that would be great, but they can't. They are interrelated in their behavior and operation.

This is why writing Unit tests for U.I. code generally does not exist. The logic required for unit tests would modify the code (thus changing it's behavior), not handle the related states and behaviors so that what ends up being tested are the tests and not the U.I. The side effect is to make the U.I. even more complex to update, modify and maintain. Not a good place to be.

With some good behavioral and design patterns this can all be mitigated. The working with multiple "behavior" balls in the air and making sure that the design patterns I have in place cover the U.I. needs.

This is what I find fun and challenging.

Sad

2011-10-05T20:23:00.002-06:00

Sad.

A Quick Look Back

2011-10-02T15:45:00.002-06:00

Cleaned out the garage this weekend and found some old development software that I had used "back in the day". The things that struck me were :
- The emotions that get evoked when I think about them -and-
- The core of development changes very slowly but the tools / technology churns away.

The first product was Symantec's "Visual Cafe" (1996). This was an early Java 1.0/1.1 IDE that was a big hit for a short amount of time. Back then it costs $299.00 when very few Java IDE's even existed. Java is still here but Visual Cafe is long gone.

The other product (1996) was IBM / Apples "OpenDoc" technology along with SOM and it's implementation of CORBA. Whew, what a mouthful. This was a response to Microsoft's COM/DCOM and embedded technology used in Office (think Excel inside of a word document). Terribly complex stuff that 1) failed to be adopted by a critical mass of developers and 2) supplanted by the internet.

Wow, what a time trip finding this stuff. So what technology are you using today that will be extinct in a few years?

Twitter

2011-09-30T19:24:00.002-06:00

I'm now on Twitter! It's been awhile and I'm exploring how best to network with others interesting in Buddhist Software Development (or just Software Development).

I'm also revamping my www.BlueFootedBoobie.com web site that contains my MySines iPad and iPhone/iTouch applications. The changes will also include information on how to setup and work with developers from a management point of view.

My handle is #ToddBlackley.

My tweets maybe questions that I've axed myself many times that get me thinking, comments of the day or just a quick observation. I hope you find them helpful.

See ya in Twitter-sphere ...

When Do You Stop Dancing?

2011-09-19T20:04:00.000-06:00

We don't always stop dancing when the music stops and our song is over. We learn to love our ruts, our comfort zones and fail to notice that the music has stopped and it's time to change.

But it's change that we should always be planning for. The world is not static and neither are companies, projects or even ourselves, so why are we so surprised when the music stops?

We see this all the time with friends changing jobs, moving away, marriages breaking and always try to come up with what went wrong, what reason is there for this occurring.

That's the wrong question. The real question is why does it not occur more often? When should we reject change and when should we adopt it? Too much change and we spin our wheels with undirected motion, too little and the world moves on without us.

Then the music stops. Maybe you did not even notice it and you are still dancing. Maybe when you where dancing you should have learning some other songs or other steps. Did you ever think that it's you and not the song that needed to change?

I myself have gone through a number of major changes (all good, mostly painful) in my life but I've always knew there would be other dances. I don't know when my music will stop (I figure it will be years away), but I'm planning on it.

But right now it's a pretty good song.

Are You and Expert?

2011-09-05T20:20:00.001-06:00

If you have been in the software development field for any length of time you've had to wear many different types of hats. There the DB, API creation, Web design, Web code/JS, remoting / streaming, UI, Requirements, Architect, Help system, Error handling, Customer service and a zillion other types of hats that are required for a typical project in our field.

I enjoy all of these different roles that I've needed to perform, however it does not make me an expert in them all. I'm good in most of them, expert even in a number of them, but I know where my strength and weakness lay. I must still learn from others.

In my youth I wanted to be an expert in everything. Learn something new then I would quickly become an expert. Well, not so fast, wanting and being are not the same and I needed to learn that.

I first needed to become an expert at myself and that took time. I needed to understand what I knew, what I did not know and when it's helpful for me to provide comments and opportunity to learn.

I have found (and this is just my opinion) youth wants to be involved. It's fair, when we are young the world is our oyster and our own self knowledge may be overstated but our enthusiasm is not. Later in a career the perspective may be reversed. Our knowledge may be greater but we now know how much more there is too learn and, this is very important, when we should provide input on what we do know.

I'll give some examples that you may have seen before :

- If you are in a meeting where everyone has strong viewpoints and wants (demands?) to be heard, you may want to take a look around the room. Is everyone in the room an expert on the topic? What is the age group represented in the room? Is the discussion calm or anxious? I've been in so many meetings of this type early in my career that it's a wonder how anything got decided.

- If you are in a meeting where there is a calm flow of thoughts and ideas between a few of the participants with a smattering of "stupid" questions that re-focus or re-base the topic at hand then you may be meeting nirvana. The primary discussion is between the topic experts with the "stupid" questions coming from the non-topic experts working to learn more. The "stupid" questions are not stupid at all, but are an active part of the questioning that is used to attach the current topic thread to a foundation where others can provide valid input. It's a learning process in action and a path to becoming an expert (after your 10,000 hours, more or less).

Asking what I call "stupid" questions can seem like exposing your lack of knowledge, and it does, but it also exposes the current topic thread of not being based on reality or facts. It can add a breather to the flow to provide a quick re-evaluation of the issue and validation that it's on the correct path. You may be surprised at the path change that can occur after the question.

The becoming an expert in yourself is for 1) knowing what you are and are not an expert in and 2) when you can provide valuable input in a discussion and learn from others. Without this knowledge you risk thinking you are an expert when you are not.

The risk of thinking you are an expert can be detrimental to yourself, your career and to projects that you are involved with. You can fool yourself into believing almost anything, but you can not fool others involved in the project or your customers.

Generic -vs- Specific Code

2011-08-29T20:35:00.001-06:00

The bottom line for me is to provide something that others (we shall call them Users) find beneficial . We take generic tools (languages, DB, logic) and hopefully turn it into a specific tool that solves some problem.

The basic software stack contains the most generic code on the bottom with subsequent higher layers getting more specific (through business logic and APIs) until the most specific code resides in the UI, that hopefully solves a specific problem.

The problem is that, as good little OOD engineers we just love re-use and generic all-purpose code. We are always looking to making our logic, features and code as generic as possible because we just know that we may re-use it sometime in the future (yeah sure!). Sometimes we try to push the generic code up through the layers and expose them in the UI, you know, because we love re-use and such. It's in our nature. Because we are sure the user will understand and love our code too. We just have to convince them what a great feature it is and how it benefits them.

We add complex syntax, tools and options galore so they can do almost anything, except solve their problem out of the box. Simple for the developer, lousy for the user.

We don't just do this to our users either, we do it to other developers too. Ask for an API to do X and we may get an API back that does (a+b+c+z) so that we can get to X, because it's more generic, it's better. The closer the code is to the end feature (UI, Service API, presentation, etc.) the more specific it should be. At this top most level we should not be trying to write the next great tool or concept, but a solution for the user on the other side.

This is yet another area where you have to separate your desires from what your users need. Your personal goals != User needs.