Replacing a 1st Gen iPod Nano headphone jack

A few years back, I was lucky enough to win an iPod Nano from the Clock Tower Law Group (because I returned a data sheet at the right time). It was pretty cutting-edge at the time and I really enjoyed listening to podcasts on a variety of subjects during morning runs. For about three months. At that point, it was "borrowed" by kit and kin and I've barely used it since. C'est la vie.

My wife, who is studying voice, relied upon the iPod heavily. She listened to music she was studying, new songs, recordings of her voice lessons, and warm-up routines. She would use the iPod to get her voice work in where ever possible; no small challenge while raising five children. So, when the iPod stopped working reliably, she was at a loss.

The symptoms were that the sound was not coming reliably through both headphone ear buds. I tried swapping headphones, listening to different music and as many other diagnostic comparisons as I could manage. I wish I knew how to put the iPod into diagnostic mode then. (Press and hold the center Activate button + the Menu button until the phone reboots. Then move your finger from the Menu button to the Left Arrow button and press and hold the Activate and Left Arrow button until the diagnostic menu appears. Press Activate + Menu to reboot when done).

Nonetheless, I determined that the headphone jack was defective. I despaired at the thought of trying to pry open the iPod and replace the headphone jack, but since the darn thing didn't work anyway, what did I have to loose?

I googled around for a 1st Generation iPod Nano headphone jack and purchased one for $6 from Binh An at bureenz@gmail.com through eBay. He was very helpful even when I initially purchased the wrong generation headphone jack. I also picked up a replacement battery since I knew I would have the unit open. Mr. Binh included an iPod tool for opening the unit at no cost.

I followed the directions at www.ifixit.com to open the unit and remove the motherboard. The headphone jack is held to the motherboard by a screw and there is a small nipple under the motherboard that fits into a hole in the headphone jack unit. I used a pencil tip on my soldering iron and removed the old headphone jack. I then stripped off as much old solder as possible with some solder braid and cleaned up the entire area by scraping away the solder paste that appeared.

Finally, I put the new headphone jack in place and carefully soldered the four leads to the motherboard. Keep your soldering iron hot and touch the tip to the leads one at a time. Wait a moment before moving to the next lead to let the board cool down.

Then I replaced the battery -- very straight forward compared to soldering the leads of the headphone jack. I used a tiny drop of cryanoacrylate to re-attach the grounding strap before closing up the unit. Make sure the ground strap runs from the headphone jack screw to the back plate.

Check that the little tabs on the metal back plate are all in the proper position before closing up the unit. They're easy to bend when opening the unit.

I charged up the battery and ran the unit through the diagnostics. Everything works perfectly and my wife has her iPod back for less than $20 in materials.

Software Development Process and the Start Up

Start ups are great places, if you like that sort of thing (and I do). Small groups of individuals infused with the entrepreneurial spirit working intensely on their Next Big Idea is invigorating. Strong, smart people can make a huge difference, albeit sometimes with herculean efforts, but at some point (more on this later), you launch.

Then you go right back into it the next day.

Which will eventually burn you out.

But greed and excitement are wonderful things, so you muster your energy, take a deep breath and dive back in. The launches are satisfying. The acknowledgment from your peers and management are satisfying. The accolades, press releases, funding efforts, and the promise that you are contributing to the Next Big Idea are all satisfying. But you know that it can't continue forever; that at some point the company will need to cross over from Commando stage to Infantryman stage and then eventually to Policeman stage (use what ever stage names you prefer here).

So here's the question; What do you need in terms of process at each stage?

Let's work our way backwards. No one would be surprised to find a mature CMMI and ITIL led organization at the Policeman stage. Some degree of CMMI maturity would quite natural for a company at the Infantryman stage, say CMMI maturity level 2 or 3; repeatable and documented process, improvement processes and some feed back capability.

But what about Commando? What about start ups? Eventually the commandos will move on and the company will be taken over by Infantrymen, but that could take years. For how long will the Commandos be running on their own gumption?

Those who live by process know the value it brings; reduced flailing, more reliable delivery, lower defect rates, greater alignment to business objectives. However, there is the challenge of perception to overcome. Perception that process interferes with creativity, introduces bureaucracy, hinders agility and is too expensive. Especially within the start up environment, which is often Cowboy development. "We have smart people, we don't need all that process stuff"

Poppycock and balderdash.

This is a simple case of "enough." Just enough process to deliver effective products. Just enough framework so that everyone knows that stages. Just enough practices so that a repeatably effective cycle can be created. Just enough monitoring and feedback to that mistakes are not endlessly repeated. Just enough borders to ensure that goals are repeatedly redefined to the point of ineffective thrashing. The basic check list is short:

• Short, but effective cycles -- this allows for flexibility and redirection without throwing away effort.
  
• Clear deliverable at the end -- the thrill of victory is a strong motivator
• Clear success factors -- New features in this build? Then only new features. Bug fixes? Then only bug fixes. One new feature and three critical bugs? Fine; do only that. What is the least amount that you can do to be successful in solving todays problems.
• Blessing and direction from senior management -- no sponsor, no work. The stakeholders decide what is the most important thing for them to have.
  

It is quite possible to respond to the short-cycle real-time demands of a start up. After all, the start up is first an idea. That idea will be tested by your customers, who will then tell you what business you're in.

All that stated, you have product to deliver. There is time pressure, and although there are unending pressures to constantly change, tweak and improve your product, you simply HAVE to launch. You HAVE to get to a launch date and the product MUST be released. Never loose sight of that.

So then the next question is "How can you manage the exchange of endless pressure with the real-time need to deliver?"

This is the job of product management. Product management starts with industry and market knowledge, time to market and market opportunity, cost to develop and return on investment. The funnel of endless ideas must be quickly and efficiently evaluated by a capable product manager. The value of the idea needs to be quantified without romanticism. The cherry picking becomes much easier at this point.

In summary, enough software process in the start up will produce superior products more effectively than ad hoc or heavy handed models. Focusing the development work on valuable efforts comes for successfully vetting the opportunities and defining the critical success factors.

There Is No Box

Here is a concept that came to me a while back when I started my own product development company, Innovatium: "There Is No Box"

The reference, of course, is to "out of the box thinking." That was practically a mantra at a previous company. At the time it was a good mantra. Engineers had a tendency to look at a problem from their perspective and apply to it their known solutions. The Out Of The Box mantra helped to express that, as engineers, we needed to push ourselves out of our comfort zone for more creative solutions that would benefit our customers.

For example, did we really need a $24,000 multi-card computer when two $4,000 PC's networked together would do the trick? We came up with all sorts of new things following that mantra.

However, it's not enough.

The typical problem we encountered (and I lived it at multiple companies and through multiple projects) was that we were thinking outside of the engineering box, but within another box. We often failed to understand our customer, their business, their priorities, their fears, and other critical factors.

What I learned from running my own company is that there is no box, so don't go climbing into one. You are not beholden to following the "way things are done". There are problems to solve and there is creative thinking to solve those problems. Ignore good experience at your peril, but don't limit yourself to doing things the way they worked last time just because it worked last time.

Remember, remarkable things are not often accomplished by mediocre people. If you want to accomplish something remarkable, you need to be willing to risk yourself in the pursuit of that thing. Just stay focused on the goal -- creating something remarkable for your customer -- and don't get fettered by someone else's ideas about How It Must Be Done.