Tuesday, June 30, 2009

Wireframe – when less is more

The goal of a wireframe design is to provide the review with a sense of the overall user experience, ensuring that what’s delivered is functional, usable and attractive…period – nothing else, not color schemes, not what images to use, not wording, not the glossy look and feel of a finished product. The wireframe needs to be closer to an old fashioned architectural diagram than a glossy magazine, the most essential reason behind this is to help the review focus on what the effort is trying to convey. A simple experiment (mind experiment if you want): put two diagrams in front of any person, one a black/white sketch and the other a mocked up webpage with deep rich colors and interesting images and see where the focus of the conversation is…pretty obvious and a pretty entry level IA (information architect) mistake.

I put most of the blame for poor IA on the tools being used, use photoshop and you get gloss, use visio amount of detail information that you build in comes at a high price of time and effort – a good IA tool needs to provide quick, easily updatable, clean designs…just so happens I’ve recently come across a wireframe tool that provides the clean, sketch like look along with the ease of use that I’ve always hoped for - Balsamiq Mockups: http://www.balsamiq.com/ Not free, but worth the $’s. I was able to sketch out a 20 page site in about an hour, go back through and refine in another hour…the ease of the initial creation invited revisions…making for a better end result.

Friday, June 26, 2009

Software development isn’t the only thing to suck

Intro to the Boeing Dreamliner story: http://www.msnbc.msn.com/id/31504462/ns/business-aviation/
Boeing Dreamliner - 2 years late and a lot of excuses (via http://en.wikipedia.org/wiki/Boeing_787):
  • blaming a shortage of fasteners as well as incomplete software
  • cited problems with its foreign and domestic supply chain for the delay, especially the ongoing fastener shortage, the lack of documentation from overseas suppliers, and continuing delays with the flight guidance software
  • said that insufficient progress had been made on the factory floor to complete work that was originally planned to be carried out by suppliers
  • unforeseen delays
  • another delay, this time caused by the incorrect installation of some of the structurally important fasteners
  • will face additional delivery delays of up to six months, because Boeing is not expected to reach its target production rate
  • stating that the first flight is postponed "due to a need to reinforce an area within the side-of-body section of the aircraft"
Sound familiar? I’m no critic and don’t have any airplane building experience (outside of models), but it’s sort of nice to hear that industries other then IT/software have their problems too. So, the mighty engineers aren’t so mighty after all and the giants of efficiency and getting things done also fail. It’s like dancing on someone else’s grave…but, let’s get the dance over and see if there are any lessons here.

To many new things:
new technology (carbon fiber) + new process (offshore’ing the work) + new relationships (either new offshore companies or at least new types of interactions with them) = trouble.
To many new factors to properly control. Maybe the offshore activities should have been tried with existing manufacturing and any new R&D type of product first needs to be developed onshore with known/skilled resources.

If you’re drinking a gallon of coffee don’t blame the dog barking for lack of sleep:
Fasteners, fasteners, fasteners – seems to be a recurring theme (at least on the face of it). If the same issue keeps arising, make sure it’s the root-cause issue and then attack it. In the IT world you often hear about Quality issues or integration issues and then management focusing on hardware (or whatever they’re comfortable discussing) to correct it….find the real problem, doesn’t matter if its within your comfort zone, and deal with it.

Most of the times, you don’t need a crystal ball:
If you’re having problems throughout the entire project, don’t wait until the end to tell the users that their expectations are not going to be met. Fewer features, lower quality, slower performance or whatever the impacts are from a problematic project need to be clearly communicated out to the sponsors and clients as soon as possible – but not before the confidence in being able to deliver to the new date and expectations level are set.

Friday, June 12, 2009

All Pain and No Gain

Clients are still unhappy, your manager is not patting you on the back, the developers grumble about everything, the projects are still not getting done timely or with quality and you’re running out of beer. Project Managers often go into new situations with the best of intent only to find that process changes provide poorer results then what existed…why is that? In most cases the answer is simple – the wrong problem was addressed. The Gantt chart, resource allocation , bug tracking, task management wonder tool was used like a circular saw in a ice cream shop – resulting in havoc, despair and unemployment.

Political, territorial, ego sensitive, insecure, unsure, over bearing people (aka The Team) who have trouble being in the same room with even themselves will have no problem entering time estimates in project plans or nodding their heads in process review meetings, BUT try to get them to truly change to a more productive and cooperative relationship with others, based on a Gantt chart, is like trying to pry a icy cold beer out of my end-of-week tired of the nonsense hands, it ain’t happening.

Rule #1 – know thy problem, don’t listen to people when they’re telling you the issues, LISTEN to them, are they naming names, are they talking about past attempts that failed, are they sneering at you, do they seem distracted, focused on everything but their area of responsibility, are they there or mentally removed? Look at people’s desks, how they interact, the environment they’re working in and how they treat each other. Do the managers provide clear direction? Do people show up on time OR at all to meetings?

Rule #2 – assume you don’t have an answer, don’t come into a situation with a answer before you really now the problem (go back to Rule #1). It’s easy to look back at historic events and come up with better plans (gee, if I was George Washington I would have purchased some of the new tanks to take care of the British…) THE tough part is coming into a situation not knowing how it’s going to turn out and actually making a significant positive difference. Spend time with Rule #1 before even thinking about the solution.

Rule #3 – communication and consistency, nothing unexpected should be done and whatever is done should be consistent. Let people know what your planned changes are, tell them what impact it directly has on them, tell them the truth and consistently apply the corrective actions – if there were no exceptions there would be no need for the rules.

Rule #4 – don’t back off, but don’t close your eyes to change. Change is tough, getting people to change habits is a painful process – search out the positive and acknowledge and reward it, search out the negative and apply the appropriate correction, don’t shy away from the job…and don’t close your eyes to the possibility that all of your plans are correct, be open to change and rethinking, but be cautious about any decision to move off course – over correction is sometimes worse than no correction.

Rule #5 – realize that it doesn’t end, there’s no end to improvement, there’s no end to doing things better there’s no end to problems….

Wednesday, June 10, 2009

Learning Python

I’ve been spending a good amount of time recently learning Python. Why?
  • ego – I want to be able to walk the walk and speak somewhat intelligently with other tech heads
  • staying relevant – I have another 20-25 years of employment ahead of me…
  • seems like the new Java – I never learned Java (not sure why ) and always felt left out (back to #1 – ego)
As a project manager, my needs for learning Python are different than they would be if I were a developer, the level and depth of understanding are different, but the need to understand the basics and application are the same. I’ve always felt that a good project manager needs to have a good technology background, this provides for insight into development and a common ground for communication. Imagine a PM with mainframe and COBOL knowledge only talking to a 19 year old php/MySQL developer…could be lots of talking going on, but little real communication.

What does learning really mean? I’ve seen a lot of people learn a lot of things, but few actually gain an understanding and the ability to apply the learning. To me, the true test of learning is the direct application (base learning) and extrapolation (advanced learning). Reading a book, typing in examples and getting expected output is just the knowledge that there’s something out there – here’s an excellent Buddhist look into knowledge: http://www.sacred-texts.com/bud/mzb/oxherd.htm ..
Another aspect of learning is understanding WHY it’s important to know what you’re studying, why other people see it as meaningful (insight into others) and why it’s getting the focus. Much of which I’m still trying to get my hands around in regards to Python.

So, what steps did/am I taking in learning Python? Basic google’ing Python was the start, which quickly lead me to http://python.org/ - the official Python website. From there I moved to Active Python- http://www.activestate.com/activepython/ - where I downloaded the interactive Python interpreter (and later Komodo edit for a better editing environment). Having an interactive/interpreter made learning and experimenting a lot easier – typically a new language means a new IDE, finding a host or setting up a development environment, etc. – nice thing about Python (one aspect of why its getting the buzz) is the low pain threshold of starting. Being ‘old school’, I also purchased a couple of books – O’Reilly Learning Python and Expert Python Programming: Best practices for designing, coding, and distributing your Python software which I’m still reading. I followed the typical approach of skipping around to interesting sections and trying the code out in the Active Python Interpreter….another important source of help was StackOverflow (http://stackoverflow.com/) – tech heads ready to answer the most basic questions.

So, now for the good, bad and ugly aspects of Python – SO FAR, I see Python as a very clean, easy to use multi-platform programming language. In many ways it reminds me of Pascal, back in the 80’s (aging myself), a step in helping programmers program correctly. Being a new language, specifically developed for its currently environments, it does not have a lot of the quirks and kludges php, c# and other languages have (if I offend…oh well). The ease of learning (or unlearning and relearning) is there and the interpreter provides for ready/quick feedback. I’ve:
  • .played around with creating a UI (Windows) – not a pleasant experience
  • interacting with various data sources, like websites, files and databases – fun and easy
  • built classes, generator functions, modules – very easy and eye opening to the strength of Python
I see Python (my opinion) as a solid clean language – good entry for non-tech heads and experienced programmers alike (similar to BASIC), the typical evolutionary but not revolutionary steps of technology. Would I recommend it as a platform for development? Yes (depending of course on the actual needs), would I recommend it as a learning platform for new techies or those needing something more than excel – YES. I’m not sure of its stability or performance issues – but, seeing its implementations and uses would expect them to be at an industry strength level (outside of high use sites like Facebook – but I could be wrong).

Next steps for me include:
  • finding a project that I can use Python on (currently looking into creating an opensource requirements management project)
  • looking into Python web development frameworks (seems to be a decision between Django and Pylons)
  • still looking into the interesting python’ic aspects of Python. One pattern I’ve found interesting were the generators (using yield within a function) and redefining superclasses…huge improvements over what I’ve experienced in other languages…
If you’re interested in Python, I strongly suggest installing Active Python (about 5 minutes) and going through the Python.org tutorials…