Success Stories
Team Building
A dead product was being restaffed after its successor failed to meet market needs. It was a really exciting product, and I applied to be the manager (even though it was a reduction in pay from the consulting I was doing). As the project grew, engineers were added as they came off of other products. I built an excellent team of senior network engineers. But as the team expanded past twenty engineers, not a single one of them was interested in being a manager. So, I created lead engineer positions and gave them lots of coaching. As each of them developed good leadership skills, I twisted their arms to accept management positions. They all became very good managers! After I left the project to revive another product, the team continued to grow. Most of the people I promoted to managers became directors and grew their own management team.
Remote Management
As a market strategy, we started buying up our competitors. This gave us teams in four different cities in two continents. There was some pressure to eliminate some to the teams to simplify the structure of the organization, but the cost of restaffing locally and then transferring the knowledge was going to be very expensive. Teleconferences were not enough to tie the teams together. I convinced the company to invest in high-quality video conferencing technology. This allowed me (and some of my managers) to participate in a portion of all regular meetings. With a little shuffling of meeting times to avoid meeting when some of the people were in bed, it worked very well. We could afford to fly some of the more significant members around, but the majority of the team knew each other only through video conferences. This was enough to build a cohesive team. When we requested nominations for our annual engineering awards, the best people were nominated by their peers in all four cities. It really was one cohesive group, retaining all the experience from the different companies merged together, not just the remnants of some once-great teams. (Note: the power of video is not that you can see what people look like, visual communication is needed for meeting dynamics. Who wants to speak? Is everyone bored and ready to move on? Teleconferences can't do this well enough.)
Test Automaton
A medical product I was hired to help validate required very exhaustive testing to pass FDA standards. It was a small appliance with an embedded processor, so the tests were being run manually by test technicians using detailed test procedures written by a large team of test engineers. But writing test procedures at a very detailed level took a very long time, and the tests could not even be fully debugged until the product was almost complete. This left nothing but unit testing for most of the project. I found an unused pin on an IO port and convinced an engineer to install a primitive serial driver on it. This allowed me to stuff in any keyboard command and retrieve a few bits of information back. That was enough to build an automated regression suite that could be run every nite. Every morning the development team go a list of new features that were now working and a list of features that used to work and were now broken. Nothing makes debugging go faster than fixing code you just wrote and still remember. This was such a productive concept, that it became the center of a paper I wrote. [download the PowerPoint]
Clean Software Architecture
Twice, I worked for companies who were designing a user interface for a small boxes with embedded processors. Previous designs had used brute-force code to implement every screen in the GUI. I scrapped the old code and designed a table structure that could express all the needed screens. Then I developed a little interpreter that could traverse the table and display the data as a GUI screen. The data structure allowed for a pointer to operational software to allow the screens to actually operate the machine. The GUI was debugged and running in one sixth of the estimated time, and adding features later was equally efficient. Good designs save time and money while providing better quality.
Quality Metrics
A server performed geographic processing for a huge mainframe application. Unfortunately, the quality of the underlying data was uneven. The end customers were paying for results, but only wanted to pay for high-quality results. If we determined the quality based on the quality of the underlying data, large areas of the country would be exclude, and the product would not be perceived to add value. I invented a new kind of statistics for calculating the quality of a query based on the relationships of the underlying data. The statistics were a much better prediction of the accuracy of the results. This allowed us to sell many more transactions, base on their high quality results. It also removed low-quality results from areas of high quality data, so our average correctness went way up. See the paper
Quick Tools to Get Back on Schedule
A client had spent years developing an elaborate compiler for a custom specification language that produced the data tables the product needed. It was validated on small test specification and declared ready to use. But the language required complementary definitions for each pair of objects in the table. The size (and complexity) of the table increased exponentially with the size of the table. When the specification team slipped behind schedule, I was asked to help. It just took a few days of working on the specification to realize that the specification alone was going to take much longer than all the rest of the elements of the project combined. I noticed that there were huge symmetries in the table data, but the compiler could only express hierarchal relationships. I specified a new language that was simpler and could inherit characteristics from macro specifications. But there was no time to write a new compiler. I borrowed a Perl programmer for three weeks. and did an iterative design with three days sprints. The basic functions were running in a week. All the critical features were in by the second week. And in the last week, we optimized and tested. (Perl made a very slow compiler, but to make the schedule, we could afford to wait a few minutes for a compile.) In a couple weeks, we had a full specification of the system and were off of the critical path. The product was delivered near the promised schedule and a million dollar penalty was avoided.
Action
A client won a phase 2 government proposal to research a specific topic. I was asked to take on the project. The phase 1 proposal was already full of ideas that may or may not have any merit. I wanted to do something to give us a greater chance to get a larger project funded. So, instead of spending the limited amount of funds writing proposals, I put together a small team and started writing code. This was an Agile project long before that term was in use. I wrote stories in short Word documents and we implemented them in several day sprints. It was a data driven model of a very complex system, so a lot of time was spent on the data. I researched real systems and converted the analysis into data for our model. The other members of the team crunched code to bring the model to life. With the tiny bit of money we had, we were able to do a very impressive demo, and we attracted a lot of attention.
Hardware development
A While developing cutting edge hardware to measure ultrafast signals, the results were not consistent. The technology was so advanced that there was no test equipment available that could keep up with it. It made oscilloscopes and logic analyzers useless. I was brought in as a contract engineering manager to try to solve the problems and bring the product to market. So, instead of using anything calibrated, we fed the devise massive amounts of random data and graphed the results correlated with different events. First, we found that the previous attempts to compensate for the errors were creating more errors. We replaced a 16 term polynomial with a, nearly linear, quadric compensation curve. Then we discovered an error in the signal logic. Finally, I noticed a bimodal distribution of the data. By walking through the circuit board layouts, I found a point where two paths that needed to be identical were not. Soldering on a jumper improved the consistency of the results by an order of magnitude.
Diagnostics The product was a protocol converter; it was a circuit board with a cable on either end. The development and debugging were done with an in-circuit emulator. The emulator would let you walk byte by byte though either code or data, but it was very difficult to see anything important at that low a level. The circuit board was a general purpose board, and had an unused serial port. By implementing a tiny diagnostic monitor, we could display any of the major data structures in a formatted display. Single keystrokes displayed each structure, and we made the diagnostic monitor smart enough to follow pointer and know data types. Debugging that had taken hours before the diagnostics were ready now took minutes. It was like being a doctor and having an MRI of every part of the body instantly available at the touch of a button. The programmers still had bugs, but debug time was considerably shorter than other projects, and that had a huge effect on the schedule.
|
