"Grandpa Tim, tell us about the old days."
Grandpa Tim set aside his reading glasses and programming text. "Are you sure, children? It's nearly bed time. Maybe a story about ponies and puppies?"
"No, Grandpa, we want to hear a scary story!"
Tim looked around to be sure the lady of the house would not overhear and scold him for giving the little ones nightmares. "Very well," he sighed.
"In the old, old, olden days programmers were isolated from each other by many barriers. Companies did not allow programmers in other companies to see their code, or to look at other companies' code. They built legal barriers and contracts that programmers had to sign if they wanted to make a living. This way, ideas could not be shared across company barriers. In many companies, they did not allow access to the internet for fear that ideas could escape from one company into another, or that people would spend time learning instead of typing."
"But if you don't learn, how do you know what to type?"
"This wasn't the way people thought in the old days. They thought that programmers should learn before working, not while working. They didn't send them to conventions, and they seldom offered training. It was before people understood 'maximize learning', so they marginalized it.
"This was not the full extent of isolation. Within the company, they further separated teams by splitting them across time zones so communication was more difficult. Then within any one location, they would separate small teams from each other with different management structures, and put them in separate rooms."
Big-eyed, Leah asked: "At least the people within teams got to work together, right?"
"Well, no. Within a team, the programmers were even more divided than among locations or companies. They were separated from each other by cubicle walls, and discouraged from talking to each other."
"Even by text messaging?"
"Especially by text messaging. In addition, each developer was given an individual task, so that the teams were not teams at all. They were all working on different things. One more division existed and it was more powerful than all of the others: they pitted the developers against each other and rewarded individuals instead of teams."
Ian reflected thoughtfully, "So the best programmers got the most rewards? At least that part was fair."
"Well, no. The rewards were based on everything but skill. They were given to the one who spent the most time in his isolated cubicle space, the ones who cranked out the most sloppy code to get features done, and the ones who could blame failures on other programmers credibly. Sometimes they were rewarded for conforming to the corporate structure better than their peers. Often the worst programmers would be rewarded, and promoted over their brethren. Most programmers realized that if they helped their colleagues, it would actually count against them. This was the most isolating practice of all.
"Yet beyond isolation was a problem even more troubling. Programmers and their bosses were afraid to write code. They worked on systems they didn't understand, and were not free to explore the code. They were not allowed enough time and communication to understand the design of the system, so any change they made could break existing features."
Ian interjected, "But Grandpa, the tests tell you if you've broken anything. It's not that hard!"
"No, Ian, it was not so, because in those days the programmers did not write tests before writing code. Managers thought programming was about typing the answers into the computer, and didn't realize it was about understanding the code and inventing good answers. They tried to improve productivity by cutting down on programmer testing, and some convinced themselves it was right to do so after seeing how difficult, slow, and expensive after-the-fact testing was."
"I don't understand, grandpa." said Ian. "If they don't have tests, how can they refactor?"
"They avoided refactoring. The programmers did not want to create errors, and had no good way to catch them before release, so they tried not to touch any existing code. They were afraid of undetected errors being released. Instead they would patch changes onto the software with the minimally-invasive techniques, like copying and pasting code or patching the code with flags instead of extending the design."
"But if they couldn't refactor, how could they steer the design?"
"They avoided changing. They hesitated to change direction even to please the customers who paid them. They were afraid that any change could wreck their existing plans and their existing code. In those dark days, programmers and their companies were very afraid indeed."
"Didn't the partner help them be more brave?" asked Leah.
"No, darling. Managers assigned work to individuals. They reasoned that two people using one keyboard would type only half as much code as two people working alone. Again, they didn't understand that the bottleneck was thinking. So without tests and without programming partners, the isolated programmer often didn't really understand the system he was working on and was rewarded on how fast he churned out features anyway."
Leah frowned. "If it was like that, why did people code at all?"
"They wrote code because they loved it and love covers many sins. They could overlook the poor workspace, the lack of community, the isolation, and the fear because ultimately they loved coding and testing and solving problems. You would be amazed what people will do out of love and the joy of creation. Even in the darkest times, programmers were people who loved their work. They would have programmed even with six-year old IDEs and outdated technologies and operating systems. They would program when the rewards systems turned against them.
"Even then a programmer could make enough money to support his family, so there were people who didn't like programming but did it anyway so that they could pay their bills and have other things they liked. Because they didn't really love the work, it was hard for them to learn new ways and improve their world. Few of these programmers survived past the Big Change.
"Around the turn of the century the world changed. During the 1990s and early 2000s the agilists started breaking down cubicle farms and replacing them with shared workspaces. They were successful in promoting pair programming and teamwork in many companies. They promoted communication within teams, among teams, and even got many businesses to allow access to the internet and the programming community outside the company. They had continuous testing, continuous integration, and continuous release. As we got into the 2000s, the craftsmen came and broke down barriers further, setting up programming studios where people could come and program with their developers on actual projects, for free. They promoted practicing programmer skills. They set up code camps and dojos and hackfests, and wore down the old ways with quality, teamwork, and community.
The old way did not die out right away, but over time all software developers found that the world around them had changed substantially. Some of them left the isolated cube-world for the open, transparent studio. As the new ways showed success, more conservative businesses started to change. A few bastions of the old world, some small and some large, held out until the end when the more agile companies started to gain market share on the strength of their flexibility and shorter time-to-market. It was a sad time for those who didn't learn."
"But it's good when the bad companies go away, right grandpa?"
"Ian, it is always good when people get new opportunities and learn better ways of doing things. It is always good when people start working out of joy and not fear. Yet it is always sad when companies close and when people lose jobs. Those who were content in isolation from new practices and the programming community struggled horribly when they lost their jobs. Some of them adjusted, some quit programming forever.
Now it's getting late. Don't worry about old times, they're all gone now. The world changes, and brings new things every day. It's time to go to sleep. Who knows what we might learn tomorrow? It's best to be fresh and excited and ready to greet the day."
Leah stopped by the staircase on the way up to bed. "Grandpa Tim," she said, "I'm never going to be afraid to write code."
"No," grandpa Tim said, "I think you never will."
You keep telling yourselves these myths. The fact that you pretend to know what development was like is pretty funny. You act like there is a lack of communication yet if you actually go back to say IBM in the 70s and read the accounts, the issue was to control the communication of 100+ people in order to reduce work and build efficient communication hierarchies to avoid wasting everyone's time. But I guess I rely upon evidence where as another might rely upon stories.
ReplyDeleteJust for the record, I've been programming (paid) since 1979 in some large companies and small ones and have seen some amazing dystopias. It's not going to reflect everyone's experience.
ReplyDeleteTim
Hello, my name is Lolita Guevarra and I am the managing editor of LogiGear Magazine. I'd like to feature you as our Blogger of the Month. Can you contact me directly at lolita.guevarra@logigear.com. Thank you and I look forward to hearing from you.
ReplyDeleteSincerely,
Lolita Guevarra
I, too, started in '79. Not entirely sure what large IBM places were like in the '70s. Heard some good stories, heard some bad. Certainly, *after* I started, and even today, I see many shops that match the scary part of Tim's post.
ReplyDelete(An aside: Why not name yourself? The anonymity thing makes it hard for me to take you seriously.)
Cheers, GeePawHill
A couple points on which I want to comment. The first is learning while working, and the second is that creative side of software is often overlooked (since it's a "math" discipline...).
ReplyDeleteOver the weekend, I installed a new entry door in my garage. I had no idea how to do that, so I invited a friend (a craftsman if you will) to join me to do the work. I spent some time "doing" but also interacting with, questioning, and listening to him while we progressed through the work. He looked at things to determine the quality of his work beyond what I would have (utilizing several tests to prove the work was of high quality) and in the end, I now have a high quality door installation that is square, solid, and will work for years to come. Had I not paired with him to learn, I'd still be out in the garage working on it and spending much more than double the time we spent, probably trying to read up on what to do to install that door. While a simple example, it shows the value of learning while working, pairing, and collaborating.
On the second point, there is a HUGE amount of creativity and thinking that goes into software. Walk into any organization where creativity and thought are main components of the work and see how the environment is set up - an advertising agency comes to mind... Open space, collaboration, brain storming, non-isolation. These are all things that foster ideas and creative problem solving. Software is a mixed discipline of logic and creativity, and both attributes need to be fed.
One other item of note, we have declining enrollment in technology disciplines with our youth, and part of the root cause is the environment they perceive exists for software developers and not being attractive. The responsibility to change this lies in each of us involved in technology creation. By evolving and showing different ways to create high quality, maintainable, cost-effective and functional software, we stand a better chance to change this trend.
Having lived in many different software environments doing work ranging from Unix operating system code to retail to web applications and lots of stuff in between, my experience leads me to believe that the past world Tim describes is not optimal for solving the software challenges of today. The world that he describes as coming of age is one that we need to foster and teach. It works, I know that factually as having worked in it and delivered high quality, maintainable and cost-effective software services to customers around the world.
Different it is, and it will continue to meet resistance as it's a change. However, remember, kites fly better against the wind.
I left programming in 1990, because I couldn't handle it. I have real admiration and gratitude for folks like Tim and Hill, who stuck it out and began to create something beautiful that I could stand to be a part of. Incredibly grateful.
ReplyDeleteAll the old, bad places aren't gone. I work at one. All the more discouraging as the company is has been in the Top 100 IT places the past six years. :P
ReplyDelete