In Tales of Vista development at MSFT, Scott Berkun finds a money quote from a former Vista development manager. After finding resistance when reporting the truth, particularly of but not limited to slipping project schedules, engineers tend to fold. Travel 3,000 miles on foot within 2 hours? You, got it boss!
An article claims that Backward Switches Doomed Probe. This does not mean that Lockheed Martin’s engineers are incompetent. Aerospace engineers are highly respected for the engineering problems they have solved and continually face. The article, instead, discusses the possibility that time and cost constraints on the production of the probe resulted in the probe’s failure. This brings to mind a chef analogy that I consistently use to control production schedules and damper client demands for immediate results.
Fred Brooks states in The Mythical Man-Month:
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely. But when it is not set in two minutes, the customer has two choices–wait or eat it raw. Software customers have had the same choices.
The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save–burned in one part, raw in another.
Although euphoria or a sense of power may be experienced by tightening a production schedule, doing so for artificial reasons unnecessarily minimizes a key resource that is available to an engineer for producing a quality system. Engineers pride themselves on the quality of their work. They gain pride in developing efficient systems in an efficient manner. Time is a fundamental resource used throughout the development effort. Most time is spent on coordination and planning to minimize the amount of time that is used on implementation and error correction. If an engineer takes time in implementing a system, it is simply because the engineer is building a system that works well. Fred Brooks notes, “More software projects have gone awry for lack of calendar time than for all other causes combined.”
After setting up and testing network monitoring software for one of our co-lo sites, it became apparent that mx.messaging.sprintpcs.com was rejecting connections from the monitoring server. I used typical methods, which include using telnet to connect to the SMTP port while analyzing the connection with a packet sniffer, to determine that the problem was with Sprint’s messaging server. It is fairly obvious that mx.messaging.sprintpcs.com closes the connection immediately after the initial TCP connection handshake. Another person shares his experience with this problem, and he can only wish that others fare better than him.
Dealing with Sprint’s front line technical support is pretty wearisome. The experience parallels the “our computer must be right (and you must be wrong)” scenario that was popularized throughout the 80s. One support representative stated, “You’re doing too much to send out text messages and making it hard for yourself.” I expressed my opinion that I would be better served by a person who did not see difficulty in resolving the problem. I was later contacted by a network engineer with knowledge of Internet protocols and using SMS over their SMTP server. He was better equipped to investigate the problem on their side, and he was very capable of helping me with any issues on my side. He actually introduced me to SenderBase, a spam monitoring service that is supposedly used by many large ISPs to minimize spam. The problem was ultimately resolved, and I continue to be a content Sprint subscriber.
One thing that I relearned from the front line technical support representative is the need to treat every problem with some attention. Because a problem seems typical, it is easy to resort to scripted responses. This might be a knee-jerk reaction that is rooted in a combination of both laziness and misplaced pride. Over the phone, the front line technical support representative sounded very authoritative with years of experience in her position and required some persuasion in forwarding my trouble ticket to a network engineer. Only through a more careful investigation can a problem be found to require a new solution.
I, too, served on technical support’s front line. Control of the conversation is very important. Effort needs to be made by both parties in keeping the dialogue from degenerating into a shoutfest. After all, in the typical case, the technical support representative accepts outbreaks from the outraged client as part of their job and simply shrugs it off at the end of the day. With a reasonably calm voice, it is almost always better to seek out solutions and keep communication open when forced to do so over the phone. Talking with a phone representative should always support the underlying objective of trying all available options, which is inhibited by frustration and raised voices.
“Few businesses are as spread out as MySQL, which employs 320 workers in 25 countries, 70 percent of whom work from home,” says Fortune’s Josh Hyatt in MySQL: Workers in 25 Countries with no HQ. A discussion of this can be found on Slashdot.
The development team of a small company that I have recently joined is continually growing, and coordinating development efforts within this team requires more than controlling file permissions. Using file permissions as a primitive means of source code control worked when the team was small, but simply using file permissions and a de facto standard of appending version numbers to modified files is becoming harder to manage as the team continues to grow. Maintaining such a hacked solution kludges the operating system’s permission control without the benefit of refined control. A more elegant solution is the use of a software versioning control system, which maintains file modification history as well as refined control over source code.
By adopting a common practice of big development companies, we gain greater project manageability. I do not believe that this will significantly affect our company’s agility, and the benefits far outweigh the costs. Training developers, who do not possess experience with versioning control systems, is a short-term cost that will yield long-term returns in the form of reduced development time and ease of project coordination. The deployment of a version control system is a strong indication that the company is interested in transforming individual developers into a team of engineers. I am a strong proponent of developing team members, and introducing them to new tools and methodologies increases their marketability to other companies and utility to our company.
Many companies worry that developing the skills of their workers results in increased turnover or wage costs. I am confident that we can continue to develop our team members’ skills as we continue to grow our team. Although our team members will become more marketable to other companies, I am also confident that each member of our team is dedicated to keeping it intact. Our company has a real interest in developing all its members, and deploying a software version control system to introduce tools to our team members and improve our development practices exemplifies our motivation.