A Person, Artist, Software Engineer, Geologist.

QA, you gotta love them.  The have the job of finding issues with the code that engineers write.  This should be a very good thing, but there are times where developers view QA as something akin to goblins that live in a haunted forest and should be avoided.  This view is totally without merit. This may be related to thinking that it's a Development -vs- QA world with and "end sum" view where for every winner there must be a loser.  This thinking is very harmful as developers and QA have the same goal, to deliver great software. Staff that works in QA is the last line of defense between what we code (and test?) before the end user (expecting a fault free experience) uses it.   QA's only fault is that they point out our faults, that deep down we already know we have.  Developers could preview if we did our own QA screening, but our minds and ego prevent us from doing so.   We like to think that when we finish code, it's finished, done, ready, compl...

I've been thinking about coupling for a while now.  It's more than just one class or process knowing about another class or process, that happens all the time.  It's about using the minimum amount of coupling in a program for it's operation.   Coupling is not a 'one size fits all' issue where there is a right and a wrong way to use it.  It's more of understanding when to use it, when it happens by accident and in general, being aware of the repercussions when too much coupling exists. In my mind, coupling exists when there is a specific relationship between two classes or processes.  This relationship must be explicit where one class must be coupled by another into for some operation to be viable.  This is not the same as just passing data from one object to another where the data couple be in the form of a third data object (a model, strings, streams, etc) where the two objects are not really bound together but there data is.  This is about object...

I've been learning iPad development lately.  At first I was intimidated with : - The Objective-C language. - No garbage collection (retain / release stuff). - The whole X-Code / Interface Builder. - Their implementation of MVC and the libraries. Whew, it sure seemed like a lot but there are some resources that helped a ton.  The iTunes Standford classes are wonderful.  They tell you all of the things you need to know in perfect chunks, along with the little bits of information of "why". I was very glad to see their implementation of the MVC pattern.  Their implementation was the very close to what I have been doing for years (13+ years). The over all philosophy is one that sync's with mine. - Keeping focused on the task. - Provide only what is needed. - Use strict patterns for the UI (Views, Controllers, Models). - Decouple different problem domains. Having fun....

Us software engineers are told we are smart, earn lots of money and are so important to the company.  We also allow this to go to our heads, forget that we have just as many issues as anybody else (maybe more) and are the root of many of the problems with software development. We want to use language X because we think it's cool. We interpet requirements for our benefit, not the clients. We work to convince others that our logic is better when issues arise. We create the bugs for QA to find. We make the software hard to understand, modify or install. We are the problem. This is a part of being human and something that we all face to some extent.  Being a Buddhist means to know what our issues are and confront them every day. The sad part is that you can see this problem behavior with many developers.  When things go wrong (as they often do), you can see the pattern of denial and defending of actions that caused the problem in the first place.   This all ta...

Think about the role you play in development.  do you write new code or do you fix bugs? It's a trick question!  Every developer's role should including fixing bugs.  We created them and we should take responsibility in fixing them too.  The notion that a developer is so important creating new code that they don't have time to fix their own error is ... well... to say the least, problematic on so many levels.  It's a problem with the company, project and the code that is written. The notion that developers that fix code are not at the same level of those assigned to new features is backwards.  Those that fix bugs have a very difficult job.  They: Do not have as much knowledge about the code as the original author. Work in a wide variety of code written by multiple developers and styles. Should not break any other code.   Do not get to refactor code but have to fix the code in place with the current design.  Even if that design is the...

Our field is a young one.  Young in terms of the average age of engineers in the field doing work.  This has the unfortunate side effect of the same failures to repeat with each generation of developers.  I've been in the field to see a few generations go by and the same mistakes re-appear. Every few years there is talk (hype really) of how a new language or tool is going to revolutionize software development.  The IDE's Languages, development methodologies, etc. are the "hot new thing" in the field. But I've never found that true.  I can still code and produce the same code with the same quality as I did 20 years ago.  The basics are the same, edit, build, run, test.  Yup the tools and computers are much faster today so the cycle time is quicker but it's not 10-100x faster.  More like 2-3 times faster than decades ago.  So what makes one type of development or a project much better than another? From my perspective it's the design. ...

Every day I fight complexity.  When I look at code and when I write code, I am always questioning myself about the complexity of the code.  I look at the reasons that I find code difficult to work with our understand. Are there hidden dependancies, multiple configurations that must be dealt with for proper operation of the code, is the layout and naming confusing.  All of these factors (and many many more) are what I deal with on a daily basis.  If I find something difficult then how will others find it months or years later? My goal is to reduce the complexity of any code that I design or write so that it's design and implementation are as transparent as possible to the  operational logic that is the main purpose of the code.  This is the end goal, to provide code that does what it's supposed to do with as little impact on the development process as possible. It's not about being smart.  It's not about being super-duper fast.  It's not abo...