Elliott, Dina and Steve

I was reading "'Memo' Functions and Machine Learning" again.  It's an interesting article, appearing in Nature, before an article about mammalian reproduction, and uses balancing a pole on a trolley as an example of artificial intelligence.

In the paper, the trolley is controlled in real-time by two computers: a PDP-7 and an Elliott 4100.  I hadn't heard of the 4100 before but the Elliott and others come from the start of the British computing industry - including others you may never have heard of like LEO and English Electric Computers. You can read more about them in "Early Computer Production at Elliotts" and "Moving Targets - Elliott Automation and the Dawn of the Computer Age in Britain 1947-1976" (review of the book).

One of the pictures in the Elliott computer archives has the caption, "Switching on the Elliott 405 at Norwich City Council in 1957. The woman to the right is Dina Vaughan (later Dina St Johnston), who did the initial programming for the Norwich system." In 1959, she was the first person to start a UK software house.  This being a company that only wrote software - not software that came bundled with hardware.  The first, according to Wikipedia, was Computer Usage Company in 1955.

The best resource on her I could find was in "The Computer Journal" called "An Appreciation of Dina St Johnston (1930–2007)".  It describes how she was writing software in the mid-50s making her a contemporary of people like Michie, Turing, von Neumann and Godel.  It describes what programming was like then:

"She wrote with a Parker 51 fountain pen with permanent black ink and if there ever was a mistake it had to be corrected with a razor blade. Whereas the rest of us tested programs to find the faults, she tested them to demonstrate that they worked."

One of the first commercial jobs for the company was a control system for the first industrial nuclear power plant.  Her company, Vaughan Programming Services, was visited on the 10th anniversary of the British software industry by "Electronic Weekly":

"The staff in a company run by a woman might be expected to contain a high proportion of women, and this expectation is fulfilled", runs the EW report, "but, unexpectedly, a low proportion of the professionals employed have degrees, and there is no great emphasis on strong mathematical background in the mix of skills used."

The industry norms don't seem to have changed very much.  More details can be found on Google Books by searching, "Dina Vaughan" (or St Johnston).

In "Recoding Gender", Dina St Johnston is mentioned along with another female programming pioneer, Dame Stephanie Shirley.  A refugee of World War II, she entered the software industry as a "late pioneer".  She became interested in programming and got into the computer room by sweeping up chads, "I could not believe that I could be payed so much for something I enjoyed so much...early software was fascinating...it was so engrossing."  In 1962 she started "Freelance Programmers", the second software company founded by a woman in the UK.   Her view of the computing industry seems to be one that offered a way to address social and economic problems, "a crusade", a flexible workplace with policies designed to support women with dependents.  Originally designed to help women with children to continue to work, its charter gradually became more broad to include supporting women's careers, then for women with any dependent and in 1975 was expanded, by law, to include men.  The final mission became "people with dependents who couldn't work in the conventional environment".  She says in her biography, the company had always employed some men and at the time of the passing of the equal opportunities law three of the 300 programmers and a third of the 40 systems analysts were male.

A Guardian article, written in 1964, quoted in "Dinosaur and Co", about Shirley and the early IT industry:

"The main qualification is personality...Much of the work is tedious, requiring great attention to detail, and this is where women usually score...Mrs Steve Shirley...has found in computer programming an outlet for her artistic talents in the working out of logical patterns.

Now retired with a young baby, she has found that computer programming, since it needs only a desk, a head and paper and pencil, is a job that can be done from home between feeding the baby and washing the nappies.  She is hoping to interest other retired programmers in joining her work on a freelance basis."

The difficulties in starting a software company in the 1950s and 1960s seem immense.  There was the idea that you couldn't sell software, that it didn't have any value as a product or a service by itself, as customers expected it to be free with the hardware.  Then there is the inequality and sexism.  She called herself "Steve" as no one responded to her business letters when she used "Stephanie".  Banks also required written permission from a man so that a woman could open a bank account.  Furthermore, almost all companies and the public service required or expected women to leave their job when they married or had their first child, so you "retired with a young baby".  One of the few ways women could continue to work was to start their own company.

She mentions her title was for "services to the industry" and as any good programmer does, she defines Dames: "...recursively by saying, a Knight is a male Dame".  She recently released a biography called "Let IT Go" which includes many personal struggles as well as parts that are a more practical, British version of "Lean In".

You can listen to her talk in "The Life Story of a Pioneer: From Hi-tech to Philanthropy" (the subject of about IT and running a software company begins about 12 minutes in, the second half of the talk is dedicated to her philanthropy mostly for autism).  There's also an earlier recorded video of that talk and others on her University of Oxford page.

The early British IT industry wasn't only about commercialising military projects or solving hardware and software problems but it was a way of affecting social change - to allow more people to work more flexibly.

What Women Want: Pairing

It's not the first time I've read an article about the continuing decline of women in IT, "Where Did All the Girl Geeks Go?" continues to note the slide:

"There's a perception that being a computer science major leads to a job as a programmer and you sit in a cubicle where you type 12 hours a day and have no interactions with other people," Block said.

Yusupova noted that even if pure programming jobs are outsourced, opportunities still remain within a company for people to bridge the relationship between the outsourced IT vendors and the business side.

"These roles would probably be ideal for women who prefer to be in communication-focused roles, if they know computer science and can communicate to all parties involved," Nelly Yusupova, chief technology officer of Webgrrls International, a networking organization.

There's was a talk given recently, at a local XP group, that lead to a discussion on the benefits of things like pair programming (see "Pair Programming").

I see pair programming and other means to improve interactions between developers not only essential for better code and a better project but also as a way to improve the IT industry generally and to expand its appeal especially to younger people and women. The idea being that certain people work better in a participatory manner rather than being told what to do.

This is pretty much what an article a couple of year ago suggested called "Debunking the Nerd Stereotype with Pair Programming" (or as PDF):

Jamie wants to be a software engineer. She enjoyed her programming and science classes in high school and wants to combine her interest in both disciplines to help society through biomedical applications. Since she started college, it seems that her life has been centered on time consuming programming classes. In those classes, her professors insist that she work alone—some professors expressly forbid even discussing assignments with fellow classmates. Before entering college, Jamie was aware of the stereotypical view that programmers work long hours by themselves. Based on her college experience, now she knows it’s more than just a stereotype—it’s true. Perhaps she should forget programming. She likes the friends she’s met in her biology lab group—maybe biology would be a better major.

Having been working in bioinformatics for over a year it's startling the number of women in this area compared to IT. It seems basically 50/50 in what is essentially an application of information technology. They still write code, they still develop large applications and so on. Why does it drop to 1 in 20 or worse in IT? It does seem that in bioinformatics you are expected to work in groups and teams, they are forever interacting with each other - it seems a brilliant environment as far as productivity is concerned.

And it's not just IT or biology but it seems that there is a general benefit from greater interaction, more pairing and the like generally improves performance:

The success rate of underrepresented minorities in science courses has been shown to be dramatically improved by shifting the learning paradigm from individual study to one that capitalizes on group processes, such as student work groups and student-student tutoring.

From an IT perspective pairing doesn't only improve the quality of the software it also improves your abilities as an individual programming as well, as has been demonstrated where pair programming has been used in IT courses and the results of students in exams improved (see "Pair Programming Improves Student Retention, Confidence, and Program Quality").

I re-read "All I Really Need to Know about Pair Programming I Learned In Kindergarten" which still holds up quite well as a set of rationales behind pair programming and NCSU's Pair Learning has lots of papers related pairing, learning and making IT more attractive to more discovery based system.

Update: Finally found a public version of the nerd article.

The Centre of Excellence

The Pmarca Guide to Big Companies, part 2: Retaining great people

Don't create a new group or organization within your company whose job is "innovation". This takes various forms, but it happens reasonably often when a big company gets into product trouble, and it's hugely damaging.

Here's why:

First, you send the terrible message to the rest of the organization that they're not supposed to innovate.

Second, you send the terrible message to the rest of the organization that you think they're the B team.

That's a one-two punch that will seriously screw things up.

Via Dare.

Compliance Pays

Washington's $8 Billion Shadow "Another failed effort involves the F.B.I., which paid SAIC $124 million to bring the bureau, whose computer systems are among the most primitive in American law enforcement, into at least the late 20th century. The lack of information-sharing is one reason why the F.B.I. failed to realize that in the year leading up to 9/11 two of the future hijackers—including one with known "jihadist connections"—were actually living in the San Diego home of an F.B.I. informant. SAIC set to work on a system called the Virtual Case File. V.C.F. was supposed to become a central repository of data (wiretap transcripts, criminal records, financial transactions) from which all F.B.I. agents could draw. Three years and a million lines of garbled computer code later, V.C.F. has been written off by a global publication for technology professionals as "the most highly publicized software failure in history." The failure was due in part to the bureau's ever shifting directives, which points up the perverse nature of government-by-contract. When the government makes unrealistic demands, the contractors go along anyway: they are being paid not to resist but to comply."

Quality is Free

The business value of software quality "Organizations that develop low-quality software, whether for internal use or for sale, are always looking backward, spending time and money on fixing defects in "finished" products."

"One common misconception about quality is that it can be traded for improved development speed, reduced development budgets, or added functionality. In practice, however, most organizations find the opposite is true. In the long run, improved quality enables teams to deliver more projects on time, at lower cost, with more features. We should realize that Meskimen's law -- "There's never time to do it right, but always time to do it over" -- is a tongue-in-cheek adage for a reason. A development team that continuously ensures quality does it right the first time. By not introducing defects into the system throughout the entire development process, a team eliminates the time and cost required to find and fix those defects later on."

And why don't customers care about quality: "The simple answer is: “Because defective software works.” The reason it works, however, is because software doesn’t wear out, rot, or otherwise deteriorate. Once it is fixed, it will continue to work as long as it is used in precisely the same way."

Upgrading the Road

When Product Cycles Collide "he auto makers have looked over the fence at the short product cycles of industries like the cellular phone (typical replacement interval 18 months), and are coveting the opportunity to sell someone a new car every two to four years instead of every five to 15. This would attack a trend that's bound to be concerning the auto makers: In 2005, the median age of cars on the road in the United States was almost 9 years, up from 6.5 years in 1990 and 5.1 years in 1969."

I wonder if taking the entire mobile phone model would be good for car makers. They could provide an electric car on a contract and sell access to the required infrastructure. The product cycle probably wouldn't be 18 months but might be less than 9 years (however long those batteries last).

A Sick Industry

Respecting the whole person "There's a discussion going on about women and IT, starting with a post by Richard Jones: Why there's few women in IT. Phillip Eby responded in Is porn driving women away from the computer industry?, The Real Reasons There Are Few Women In IT -- And What YOU Can Do About It and Why (Most) Men Don't Get It -- and I personally find his analysis much more useful.

Richard's original post talks about a case where someone used porn in a presentation, and he's basically saying that is "why there's few women in IT". I don't buy it."

Links to HOWTO Encourage Women in Linux.

The real question is why people (men and women) aren't going into IT - it's not just women. The IT Workforce Conundrum "...college student enrollment in computer science programs is down substantially from the 1990s -- around 20 percent according to the Computing Research Association. In fact, the peak numbers reached in the last decade reflected the Internet boom and represented twice as many CS students as there were in the 1970s. Outsourcing is helping to meet the demand of some types of IT jobs, but many companies are still hard-pressed to find qualified tech workers.

A recent PricewaterhouseCoopers (PwC) report predicts that competition for high-tech talent is going to become even more severe over the next few years as globalization absorbs the remaining technology workers around the world. The report says that while companies have been forced to look offshore in order to gain access to larger pools of talent, even this resource is not bottomless. European and Asian executives anticipate a severe shortage of tech talent within the next three years. And, according to the report, worker compensation is being equalized globally; even India and China are not considered low-cost anymore."

The PCW Report says, "In an era of scarcity, technology companies will need to focus more acutely on their talent management. But today, in many areas of human capital management, executives’ self-assessments show little or no confidence in their companies’ abilities."

Decertification

Another Nail in the IT Certification Coffin ""Across all 253 skills we survey, the value of noncertified skills is growing at a rate five times greater than certification pay. And there's no sign that this is going to change any time soon," said Foote.

Certifications are losing value because employers are looking for more in their workers than the ability to pass an exam; they want business-articulate IT pros. "

Truth, Lies and Lines of Code

The ever quoted, "Broken Windows Theory": "Turns out they're actually great project managers. They knew months in advance that the schedule would never work. So they told their VP. And he, possibly influenced by one too many instances where engineering re-routes power to the warp core, thus completing the heretofore impossible six-hour task in a mere three, summarily sent the managers back to "figure out how to make it work."? The managers re-estimated, nipped and tucked, liposuctioned, did everything short of a lobotomy -- and still did not have a schedule that fit. The VP was not pleased. "You're smart people. Find a way!" This went back and forth for weeks, whereupon the intrepid managers finally understood how to get past the dilemma. They simply stopped telling the truth. "Sure, everything fits. We cut and cut, and here we are. Vista by August or bust. You got it, boss.""

The whacky thing still is that they're measuring productivity of programmers as lines of code, like numbers of cars produced. It's features delivered over time that counts, user visible features.

And here's part of the answer "How to refactor": "Essentially, you decide how it is you're going to write code and that's it. Product management asks for a new feature, you estimate based on your best work. What you don't do is offer choices:

"Well, that's going to affect a part of our source code that's not really testable. Cleaning that up and adding the feature will take a week, but I suppose I could get it done quicker if I don't refactor right now."

Eeek. It doesn't matter how much you decorate offers like that with warnings about how you can't really promise them the hack won't come back to bite them, blah, blah, blah... The quick-and-dirty decisions will be chosen often enough and you'll start moving backwards.

So we only write code one way and there's only one estimate:

"It will take a week. The reason the estimate is longer than similar features is because that code doesn't have unit tests yet and I'll have to move some things around in order to write them. The good news is that the next time you ask for a change in this area, it will go faster."

That's it. No choices."

Update: Peter Kantz's picked up on the same point (and similar title) and added that Microsoft is supposed to be using Scrum, which highlights the need for transparency. Via, "Microsoft Vista: Scrum or Not-Scrum".

The Greyness of Gold

Steve McMcConnell's Software Project Survival Guide mentions gold plating a project, specifically: "Implement only what is required. Developers, managers, and customers often think of small, easy changes that seem to make the software better. These changes often have much more far-reaching impacts than anticipated by the specific developer who will implement the change. Do not let additional complexity creep into the project through gold-plating."

This may fly in the face of ideas like refactoring (although refactoring is generally an attempt to remove complexity not add it). To put this into context, though, the team that he's talking about is well above the quality curve: "...the average MIS shop would need about 14 calendar months and 110 staff-months to deliver a 100,000 line-of-code MIS system, and it would typically contain about 850 defects when delivered. The NASA SEL [the team in question] would deliver a system of that size with about the same amount of time and effort, but it would contain only about 50 defects."

So when you have a manager talking about not wanting to have a gold plated solution check to see if your project is delivering on the 50 defects/100,000 lines of code first.

Of course, the original point is true too - you can continually seek the perfect solution to a business problem, probably forever, and in doing so add complexity to a system. Business processes aren't always rational so there may not be a good solution to the problem. So continually swapping ways of solving a problem can be an untenable situation.

I know that some people want to refactor code forever and others are happy just to write code and see if it works somehow. There's obviously a balance.

To me saying, "I don't want a gold plated solution" is asking not try to achieve a certain level of quality and certainly most IT shops should be trying to do more not less.

Free the Worker

Open letter to CEOs, COOs, CIOs and CFOs across the corporate world "No amount of posters, incentive programs, PowerPoint presentations or slogans on websites will affect the hearts and minds of your employees...many of your managers act betrayed when their employees tell them they want to leave the company. This is an absolute double standard and should be stopped immediately...Explain how your business works and why it is so exciting for you to run. Make them into better businesspeople so that they can grow their opportunities and net worth. And for God's sake share the profits...Don't ask for your employees' input if you are not going to listen to it...I have witnessed people playing video games at their desk until their manager leaves "just so they won't think that I am slacker." Huh? It is not a badge of honor to work 18 hours a day."

Also, Open letter to employees across the corporate world "If you want your life to grow in a positive direction, surround yourself with people who are eager to learn, problem-solve and support each other. I don't mean you can never complain - just don't get stuck whining all the time...Don't think of your job as a paycheck, think of it as a learning opportunity...You choose to be in your current situation, otherwise you would have changed it. So don't give away your power. If you are miserable, follow the advice above and move yourself to a better place."

From, Links for 2006-05-11 [del.icio.us].

You couldn't possibly be

Research May 2006: Which Emerging Technologies Make Sense For Your Company? "And we're still a decade away from the Semantic Web, according to Charles Abrams, a research director at Gartner. So how can 8 percent say they've adopted it? Abrams suggests that they may be using some XML-based specifications that involve semantics. Or maybe, says Parkinson, "They don't know what they are talking about.""

The graph shows 8% deployed, 10% testing and 25% evaluating/tracking. This makes it about as popular as Linux on the desktop and Grid Computing.