Thanks, guys, and thanks Ted for chiming in. This has been hard as you can imagine, but none harder than for the owners of DMP who have to wade through the day-to-day hassle of reading promises that remain unfulfilled and that’s my fault. I shouldn’t have promised a date or even ventured a guess because it’s not going to be accurate. And then we’ve let people down again. And in the even bigger picture and words aside, the fact we haven’t delivered any promised improvement speaks volumes.
All I can do at this point is share with you openly and honestly all that I know. We released the product with what we believed to be a few flaws that would mostly not bother people. I had been using DMP in the Music Room for some time and found CDs, data discs, and SACDs to be slow loading but operable. There were a few quirks I had gotten used to, like the first and last track swapping at the beginning of a disc insertion if I went too quickly, not leaving it in pause too long, but nothing too bad. There was a lot of pressure from anxious customers to launch the product. It was late, people were excited about how good it was sounding, and the pressure was on to ship it so people could marvel at its extraordinary performance. With the assurance from a programmer that the few remaining bugs could be easily fixed in the field within a week or two after launch I authorized the product’s release.
What I did not understand at the time, because I am an analog engineering person and certainly not a programmer, is that the control loop code itself was a tangled spaghetti mess and that the programmer responsible was in way over his head. He lacked the competency to write clean code of this magnitude (the code itself is very complicated). His ongoing patches were Band-Aids that covered up one problem while exacerbating another. It was at this time that our director of engineering, Dave, retired and we hired a new one, Matt. I had made it my business to make sure our new director was software-centric. Dave was great but was hardware oriented and we had hardware locked down solid. It was software the company was growing into. Matt’s a programmer down to his toes. He came from a team at Seagate. As he rolled his sleeves up to help the employee responsible for the DMP code (because the promised two weeks had turned into two months) he was stunned at what he saw and came to my office with a grim announcement. The code was some of the worst he’d ever seen. We let that employee go the next day and Matt, whose hands are full just being the director set out to tackle the fixes himself, evenings and weekends.
This is when I became hopeful we would see a fix soon and reported it as such on the forums. I figured he’d have it up and running soon. I was wrong. Between day-to-day tasks, he spent a month determining it would require a rewrite and was not worth salvaging. The story goes on and on and is not worth the complete day-by-day telling.
Here’s where we now are. Matt assures me he will have a much better usable version ready within weeks. I believe him because I am using a version of that fix and it makes the product a joy again to use. Is it perfect? No. But, it’s pretty damned good. We will release that new code which can easily be applied in the field in under 30 seconds.
Meanwhile, we’ve been hiring to fill in the missing position and it’s been a difficult time finding the right person to fill the embedded firmware role for a couple of reasons that aren’t worth public discussion. Let’s just suggest we don’t want a repeat of what happened in the past. We now have two options for the final rewrite. A very experienced contractor and a potential new hire. As soon as we sort those options out the rewrite begins in earnest. We estimate two months for a rewrite but, as Ted writes, software ain’t done till it’s done.
Meanwhile, you will have the better version that should put this all in the past until better shows up.
My apologies for any wrong words or frustrations I have caused by the decisions I have made on behalf of the company.