Articles Feed

Authors

Categories

Archives

Observing a Craftsman

by: paul | November 17th, 2008 | 1 comments »

“Knowledge can be communicated, but not wisdom. One can find it, live it, be fortified by it, do wonders through it, but once cannot communicate and teach it.” –Hermann Hesse, from Sidhartha

My path in becoming a craftsman was not through conventional academics. I did get a Bachelor degree in Computer Science. During those years of learning, I was taught a lot about how to learn and how to communicate, but I learned nothing about how to practice my craft of software. I learned how TCP/IP works, how registers are able to do math . All of this is interesting and some of it is useful for a broader view of computer interactions as a whole. None, however, taught me about developing software as a craft. I did some programming, which is a prerequisite for any kind of software development.

My real learning began after school. Learning software as a craft was not done in books. It took being around journeymen and master craftsmen to learn the way they think. Observing their idiosyncrasies and approach to a problem is part of the learning. Much of the wisdom is tacit. For me it is watching the way my mentor approaches a story. The way a craftsman sees a problem and digests it, without hurry, and finds a satisfactory solution. Then they write code, introducing faults and fallacies the original solution could not have predicted. Finally, a meticulous approach to improve each fault in the code. The whole time demanding perfection, without ever hitting it. This is the good code I strive to write. I can’t learn that by looking at the solution though.

These are observations of behavior and intent, not of actions. For example, I have read about Test Driven Development, and it has made my job easier. For awhile after I learned it, I wrote a lot of simple assertions, almost reverse engineering my production code in my head to figure out what the test code would look like. However, the practice itself became ten times more valuable when I saw my mentor use the tests to design their API. They would say things like “what do I want this to do” or “that doesn’t feel right, lets rename the method to this”. Those insights into the thought process provide me with the experiential learning it takes to further improve my craft. When I started thinking about TDD in a similar manner, it allows me to clean up my code and know it still works, refactor my code into easily extendable solutions, and it gives me the confidence to experiment with the aesthetics of my code. I couldn’t fully learn that from books alone.

This is why it is so important to apprentice as a software developer. There are many things about development that I only learned through watching the behaviors and actions of the craftsmen I admire. To me, these are the things that open up the software world to gain wisdom. For example, to be a better developer is not to learn a new language, but to have the wisdom to learn and understand any computer language, which requires you to learn new languages all the time.

Kata: Langston's Ant in Ruby

by: micah | November 13th, 2008 | 1 comments »


Langston’s Ant in Ruby Kata Screencast

I’ve recorded my Langston’s Ant kata for all to see.

This particular kata, with slight variations, has been in front of an audience twice before. Once at a Software Craftsmanship group SCG meeting and again at RubyConf2007.

On both occasions I asked the audience to evaluate my performance on a scale of 0-10, 0 being the worst kata you can imagine, and 10 being the best. At the SCG, my performance was longer than the screencast because I didn’t use the instance_eval trick and wrote multiple case/when statements. It resulted in much more code as well. Honestly, I felt the kata dragged on a bit too long which is why I shortened in subsequent performances. Despite this, the SCG audience gave me an average score of 8. At RubyConf, the kata was almost exactly like the screencast and it earned me an average score of 7.

Now coming from an audience of dedicated Ruby developers, I’m quite pleased with my score. Here’s some of the feedback I got…

I find this feedback immensely valuable and thank those who took the time to provide me with it.

In martial arts, the techniques performed in kata are not always by the book. There is an aspect of art, creativity, and entertainment. At several points in my Langston’s Ant kata I intentionally decided to bend the rules to enhance artistic and entertainment values. I leave it up to you whether I made the right compromise or not.

After watching the kata, leave a comment with your rating and any feedback you have for me. I thank you in advanced.

Ruby Battleship Sparring Tournament

by: micah | November 8th, 2008 | 0 comments »

Yesterday in my talk at RubyConf2008, I announced the commencement of the Ruby Battleship Sparring Tournament.

This is an open tournament. All are welcome to participate.

Agile in Buenos Aires

by: micah | October 29th, 2008 | 0 comments »

Last week I attended Agiles2008 in Buenos Aires, Argentina. It was a fun, high energy conference. The highlight was a heated panel discussion at the closing of the conference. On the Panel was Matt Gelbwaks, myself, Tom and Marry Poppdieck, Dave Nicolette, and Tobias Mayer. Tobias has already posted a blog about the event. So that my opinion is not misconstrued, I'll share it with you here.

The future of Agile is Software Craftsmanship.

Software is a young industry and we're still discovering more about it every day. Yet, it has it's origins in electrical engineering. So it's seems that, at it's inception, people assumed software was a form of engineering. And to build software systems should be no different from engineering any other creation. Take a bridge for example. Before building a bridge, you have to analyze the bridge requirements. How long will it be? How much weight must it hold? etc... Once the requirements are understood, you design a solution. Build to-scale models that you can push and stress to make sure the design hold up. Then, once you have a solid design, can you begin construction of the bridge.

It's waterfall. Waterfall worked for engineering so waterfall was applied to software. We know now that waterfall doesn't work. Agile, is a realization that software is not a form of engineering. Agile is a realization that software is a craft.

I have been to every North American Agile conference since the very first, and I have noticed a trend. In the first conference in Charlotte NC, laptops were open on every table, around every corner, with someone or a pair of people writing code. In many of the sessions, people were writing code or talking about it. This is the conference where people were bragging about their Ward number (0 if you paired with Ward Cunningham. n + 1 if you pared with someone with a Ward number of n.) and desperately trying to improve it. It was truly a conference about software. Over the years, less and less coding could be found at the conferences. This last year, at the conference in Toronto, it was abysmal. Although there was some good content, I felt like the conference had been taken over by Scrum Masters. It was no longer a conference about software development. It had become a conference about project management, people management, and Scrum. This makes me sad.

In middle ages, if you were a lord and you wanted to build a cathedral, you found a master craftsman. The master craftsman recruited other craftsmen and together they constructed amazing buildings that still stand today. These craftsman were passionate about their work and cared about creating great buildings. That is what made it work. They didn't have scrum masters telling them what to do or cheering them on. The great work they did is a tribute to their craftsmanship.

The future of Agile is Software Craftsmanship. Developers out there need to realize that software is a craft. As such, developers should strive to become craftsmen; strive to learn more about software; strive to write better code; strive to build the best software possible. The software you get from a team of true craftsmen will be unrivaled. It is the goal and quality within that drives a team of craftsmen. They'll find a way to overcome any obstacles and adapt to any changes.

Software Craftsmanship Group

by: micah | October 2nd, 2008 | 0 comments »

I'm pleased to announce the inception of the Software Craftsmanship Group. http://groups.softwarecraftsmanship.org The first meeting is October 13th at 7pm in 8th Light's office. Hope to see you there.

Customer Interaction

by: | September 23rd, 2008 | 0 comments »

At 8th Light, they follow a practice of training people through an apprenticeship period. As it is nearing the end of my apprenticeship, my mentor has asked me to write a blog talking about one thing I have learned during the course of my apprenticeship. For me, the one skill that I learned the most about was the one skill that needed the most work in the first place. The main thing I learned was that I was writing software for others. Similar to that idea came the need for increased customer interaction and learning how to interact with people in general.

Prior to working at 8th Light, almost all the programming I had ever done was either for myself, or for school projects. In the first case, I was my own user, so there was never any issue in communication there. And for the second case, the requirements were almost always very clearly drawn out(and not likely to change). Again, not much room for error. Once I came to 8th Light, I was forced to write code both specified and to be used by someone that was not myself. This was something new to deal with. For at least the first month or so, my thought process was for myself. It wasn't until I came to that realization that I was able to change my thought process. There was not one single event that made me learn this, but it was something learned over time. When starting a story, once the requirements have been approved, I don't try to change the story. Even if I don't agree with the desired functionality, it is what the customer wanted, and that's all that matters. And now, when I finish a story, I take the time review the requirements and make sure it completes all the requirements that the customer specified.

In order to provide a high quality product for another person, you must maintain a high level of collaboration with them. Without talking to them, you will never be able to guess what they want. So, in going along with the first lesson, I also learned that a lot of customer interaction is important and any issues that arise should be addressed quickly. One event in particular occurred that helped me realize this was the week leading up to one of our releases. It was around this point that the customer decided to begin some testing of the system and uncovered a number of bugs. There was some concern as to whether or not all the bugs were being kept track of in some way, and this added stress to both the development team and the customer. It wasn't the bugs that taught me anything, but the manner in which Micah handled them. After our iteration meeting, he called attention to the problem. He didn't blame anybody, but just said that something needed to be done to fix the problem and even proposed some possible solutions. It was the high level of communication between the development team and the customers that was valuable to me. This made me realize that you have to address problems quickly, and it helps to offer multiple solutions to a problem. The customer also seemed to appreciate that we brought the issue up, and partly because of this week of bugs, we introduced a new bug tracking tool to our process.

I also began to learn that if you have a question about how something is supposed to work, sometimes the best solution is to just ask the customer. At one of our recent iteration meetings, the customer mentioned functionality that they expected to be in a completed story that had never been discussed. We realized that there was not enough feedback gained from the requirements, so we altered our process to account for that. Now, after determining the requirements, we bring them to the customer and discuss them in person. This is something we just began, but it already has shown signs of success. The customer has actually come to us to discuss the requirements for some of the stories. It is because our team values communication that we were able to improve our process.

Learning these things has already helped me work more productively. If I have a question, instead of trying to spend too much time reasoning it out my own, it can be much faster to either go to the requirements or directly to the customer. During the course of my apprenticeship, I also learned a lot about coding but nothing was as important as what I learned about human interaction. This is a lesson that has definitely changed my mentality towards coding and will hopefully improve my skills as a professional software craftsman.

Definition of Software Craftsman

by: micah | September 21st, 2008 | 5 comments »

Craftsman Clarification

There has been some discrepancy in the use of the term “software craftsman”. Rather than going into details about various uses of the term, I’ll just clarify what I believe it means.

software craftsman n. A man who practices the software craft.

There are a few points to make about this definition.

1. “software craft”

A craftsman believes that software is a craft. This is important because not everyone believes this. A craftsman takes pride in his work an strives to do the best job he can. He believes that writing good software requires skill and careful attention. That software is not something that can be manufactured nor can it be delivered faster by merely adding more bodies.

2. “practices”

A craftsman practices his craft, always striving to become more skillful, to produce better software.

There are traditionally 3 stages of craftsmanship:

  1. Apprentice
  2. Journeyman
  3. Master

No matter which stage one may be in, as long as he practices software as a craft, he is a craftsman.

3. “A man”

Technically the term “craftsman” is gender specific. Women are just as capable of software craftsmanship. Indeed, I’d like to see more software craftswomen out there. In an effort not to alienate anyone we should use the term “software craftsperson” more liberally.

Update: There’s a movement afoot to make the term “software craftsman” gender neutral. Feel free to comment below.

I’ve checked with the book “Software Craftsmanship” by Pete McBreen to see if it conflicts with my definition. Although, he uses the term “software craftsman” ambiguously at times, he is careful to use the term “master craftsman” when referring to craftsmen at the height of his craft. This is in line with my definition.

I hope this serves as a reference for my use of the term. People should not think me presumptuous when I call myself or my colleagues craftsmen. I mean only what I describe above.

Own Your Tools

by: doug | September 15th, 2008 | 1 comments »

I spent a lot of time with my grandpa growing up. He has spent much of his retirement ‘fooling around’ in a workshop he built on his slice of Pike County, Illinois farmland. From a very early age I spent a lot of weekends and entire weeks of the summer as Grandpa’s little helper. I’d work on the things he was working on while helping and learning. When I was about 7 years old, I was helping Grandpa refinish a dresser. I had a flat paint scraper in my little hands and was trying to dig into the layers of flaking paint that gripped the dresser. I really didn’t have the strength to get under the paint with that big blade, so I turned the tool on edge and started scratching deeply into the wood. I was making progress now, but tearing the heck out of the surface. Now in Grandpa’s version of this story, he says that when he saw what I was doing he corrected me too harshly and sharply and later found me teared up in a corner of the workshop sorry for what I’d done. I honestly don’t remember being that hurt by his rebuke, but I do know how to use a paint scraper and dozens of other tools properly because of that time I spent ‘helping’ grandpa in his shop.

As software crafts-people our tools are other bits of software. We spend every minute of every day using software. Our editors, compilers, interpreters, source code repositories, IDEs, debuggers, and test frameworks enable every stage of our work. Everything we do to create and add value to a software project requires some other software tool to make it happen.

At many of the places I’ve worked, the developers have a laundry list of complaints about their software tools. Often, teams develop elaborate rituals and incantations to dance around the shortcomings of their tools. “Before you check in, copy this file over there then add a note to that file then spin around in your chair three times and your check-in should succeed.” Now I agree that there are lots of poorly designed tools out there. Some tools do things that just don’t make sense and others crash all the time, but I have a challenge for us as software crafts-people: Own your tools. Tools are software, you are a software crafts-person. You can find or make a tool to do anything you need.

Groups decide to invest in a tool, often at great cost, but very few people end up understanding or even using the tool. The tools usually gets blamed for its shortcomings before anyone has really made the effort to get them to work. They give up on it far to early. Own your tools. Understand everything it can do, and if it isn’t enough, find a way to make it do what you want.

One of the cool things that happens is that investing time in your tools may give you the chance to explore a new language. One of our goals as craftsmen at 8th Light is to learn a new language every year, but often its hard to justify the time spent in a new language when you are heads-down in a project. Using a new language to create a tool for yourself may give you just the excuse you need to spread out a bit and learn something new.

Is it really worth it? Can the time spent writing “non-production” code really be justified? Let’s take a task, say the creation of a new class in C++. Most people when creating a new class, will open up the last class they worked on, copy the entire thing, paste it into a new file, delete all the methods and data, then do a find/replace on the class name. There are probably a few comments that need editing, the revision history needs to be cleaned out and maybe there is a comment header or footer that needs to be updated. This entire process could take maybe 2 minutes. It hardly seems like it’s worth automating. Except … Wait! It won’t compile, because you mistakenly didn’t remove the parameters from the constructor and the compiler can’t resolve the dependencies. This is a manual process, so it’s error prone. So you spend maybe another 3 minutes getting the thing to compile. Then we need a test harness so you do the same copy, paste, delete, find / replace process. 8 minutes later we have a new class and test harness and we are ready to start working. The hour or so investment to build a tool for yourself will surely be worth it now. If you share your work with the rest of your team and suddenly everyone is saving 8 minutes every time a new class is generated, you might have your hour back by the end of the week.

Some IDEs and editors have some class generation utilities for you. This may get you part of the way there, but it probably won’t put your company’s header on the top or put in your source control keywords. It may not make your destructor virtual or create a private copy constructor to start like I like to do. The tool doesn’t do exactly what you want. Own your tool. You are a software craftsmen. You can create software that generates a class for yourself. If you are in an editor that supports macros or bundles, you may be able to implement the tool in the editor’s macro language.

In this spirit, the craftsmen at 8th light have contributed to open source software tool projects for several years. Micah is the author of the widely used Fitnesse acceptance test framework and Eric has taken over the management of Selenium on Rails. Micah’s also been working on a whole new development framework called LimeLight. We love open source tools because they let anyone own the tool.

Grandpa used to make things out of sliced walnuts. He’d glue together little baskets or crosses and fill the walnut cavities with colorful beads. As you can imagine, a walnut is a pretty difficult thing to slice. At the very least it’s awfully dangerous to get your fingers that close to a band saw. Grandpa showed me a while ago the tool that he made to save his lower digits. It’s a pretty simple block of wood with a half-walnut sized divot carved out of it. It was a woodworker using his woodworking skills to create (and own) a tool for woodworking.

If you’d like my class generator, you can have it here. Chances are, it won’t do exactly what you need it to do, so … own your tool.

Maturing the Manifesto

by: doug | August 27th, 2008 | 1 comments »

There has been an interesting discussion happening about adding a 5th value statement to the Agile Manifesto. Uncle Bob Martin proposed this addition earlier this month at Agile 2008. The proposal has centered around the idea of craftsmanship or professionalism. In his keynote, Uncle Bob proposed that we value “Craftsmanship over Crap” and in a later blog post suggested “Craftsmanship over Execution.” I strongly agree with the call for more professionalism and craftsmanship amongst software developers.

The original value statements are comparative. The things on the right still have value, but the things on the left are valued more. “We value working software over comprehensive documentation.” I think what has happened is that we have found something we value MORE than “working software.” We value well-crafted software over working software. It’s very important that the software works, but even more important is that the code is clean, that it is easy to read and therefore easy to change.

I’ve been reading “The Craftsman” by Richard Sennett. I’ve found a great definition of craftsmanship. “They are dedicated to good work for its own sake” (Sennett 20). A craftsman is driven by quality. Quality software is software that both does what is is supposed to (works) and is clean and easy to continue to work with.

This has me wondering about the other 3 value statements in the manifesto. Are there things that we value more than those things on the left hand side? We are learning day by day better ways of doing software, so what have we learned since 2001? We have a good idea about how Craftsmanship shapes the way we think about ‘working software.’ How can the idea of Craftsmanship change how we think about ‘responding to change’, ‘individuals and interactions’, and ‘customer collaboration’?

Sennett, Richard. The Craftsman. Yale University Press. New Haven and London. 2008

That's not Agile, Live

by: doug | July 26th, 2008 | 0 comments »

About a year ago, I wrote That’s not Agile. The idea has grown a bit since then and I will be presenting it as a workshop at Agile 2008. If you are coming to Toronto, please consider coming to check out the workshop. It all happens Thursday morning (8/7) at 8:30 am.

In this workshop we’ll be looking at the differences between the practices of Agile and the values/beliefs in Agile. We’ll explore questions like “What makes a practice Agile?” “Is it your practices that make you Agile or you beliefs?”

I’m especially hoping to find some people in the room who have been on a team that has struggled in transitioning to Agile.

See you in Toronto!

No Tag Backs

by: eric | July 3rd, 2008 | -2 comments »

Well Micah tagged me, and if I look at these XML request/responses for another hour without a break I’m going to pass out into my keyboard. Here goes.

How old were you when you started programming.

I had a Texas Instruments computer thingy that I got for my 6th or 7th birthday, somewhere in there. It played these educational games, but I noticed one day that if I didn’t put a cartridge in it a blue screen came up with a cursor. It had an instruction book and I would basically type in the programs verbatim, then do little things with it like change a color or a line. Later I had an Atari XE and it did the same thing, so I made the same little guessing game in it just like the one I made on the TI. Realistically I didn’t write anything of use until high school though.

Interestingly, perhaps only to me, my version of Hello World for the iPhone SDK was a guessing game.

How did you get started programming.

I guess that was the real answer. I played with my dad’s computers all the time but didn’t consider it as a career until I was about 16 or 17, when I realized I could probably get paid for it. Up until then I wanted to be a sports journalist. So I went to school so I could found my own game company.

What was the first real program you wrote?

What counts as “real”? The guessing game? Making horizontal lines appear on the screen? I wrote a bunch in Basic and Pascal for homework assignments, and like Micah had one of those TI calculators. The first specific one I can recall was a text-based adventure game I made for a homework assignment my freshman year. It was based on the Haymarket Bombing

What languages have you used since you started programming?

Pascal, C, C++, C#, COBOL, Assembly, Perl (but I won’t admit it), Java, Objective-C, Ruby, Javascript, Lisp, VB, Erlang, and I just wrote Hello World in Smalltalk (Squeak).

I too doubt I could write Hello World in most of those languages, and wouldn’t put them all on my resume. It’s funny because I probably would have when I came out of school, since I didn’t know the difference between “familiar with” and “able to write some code with”.

What was your first professional programming gig?

I started a web design company in college, which employed me and myself. I had two clients, one of whom paid me in Kung Fu lessons.

If there is one thing you learned along the way that you would tell new developers, what would it be?

Find great people to work with. If you’re the smartest person in the room, you need a new room, because if you’re not growing you’re dying. This is tricky when you’re new, since you don’t know a great developer from a tree stump, but take a look at Micah’s tag list. It looks like the list of authors in my library.

I would also tell them they should come to work for me as my apprentice, unless they weren’t any good. Then they can work for Jim.

What’s the most fun you’ve ever had programming?

Working with the team I work with now is fantastic. I also had a great time working Agile 2007 as part of RailsFest, and I’m looking forward to doing the same thing on the Live Aid stage this year.

Up Next

Sadly I don’t know many developer’s who keep blogs, so I’ll just echo Micah’s list and tell Paul, Jim, Doug and Matt they’re next.

Apprenticeship month one report

by: paul | June 30th, 2008 | 0 comments »

8th Light has an apprenticeship program whereby an 8th Light craftsman will mentor an individual for three months. During that time, the craftsperson becomes responsible for a single apprentice. I am one month into a mentorship with an apprentice. This blog is about observations I have made about myself as a mentor.

Curiosity

He asks me questions that I wouldn’t ask myself. I had him do an exercise about Law of Demeter , to find Law of Demeter violations in my code base. He found something like:

Law of Demeter

“Ted Williams”.to_s.strip.upcase

He was counting the periods, which is what I explained is often good measurement of Law of Demeter violations. Yet this is not a Law of Demeter violation. Each one of those methods returns itself (a string) in a changed state. It is not a string of implementation details- this example is just changing a single object. The pivotal piece of information is that all of these methods on string return the string itself. Also, is anything inside of Ruby core language capable of Law of Demeter? It is unlikely to change, and is there a problem being coupled tightly to your language?

I sometimes get desensitized to the original premises of good development. When I first learn something, I remember the example of the rule more than the value of the rule. The value of learning about Demeter is rooted in encapsulating logic in such a way to hide implementations from an object’s clients. When I first learned about Demeter, all I could do was point out violations. The more I developed, the more it was internalized as a guide for a higher development idea. I want to keep my modules as decoupled as possible. However, that notion only came with development experience. Now I don’t think in terms of violations or non-violations of Demeter when I read a piece of code. It is just ingrained in my developmental context that I should develop my modules in such a way that they are autonomous. This weeds out most Law of Demeter violations by itself. Bringing these premises back up in my development as a craftsman gets my curiosity started. Like a good song or piece of writing, every time I come back to it, I take something different from it, because I am in a state of constant change.

Teaching

Sometimes I forget how important teaching is to the craftsmanship model, because I am still an extreme novice at it. It is one of the steps involved with internalizing development skills. When I pair with my mentor, I am constantly amazed at how he skips steps in the development rational process. Instead of following a linear thought pattern to a solution, it seems there is a giant shortcut in the rational processes I go through. That gap is a lookup table of solutions in his head. It appears so easy and effortless. Teaching is part of a formula that has given him a development context that is superior to mine. The more I am able to teach, the more I internalize the ideas about development.

There is a baseball story from about a year ago. Greg Maddux was warming up before a game and his catcher exclaimed to the pitching coach, “I bet I could catch him with my eyes closed.” Well, after much effort, they convinced Maddux to give it a shot. The catcher was going to call his pitch, then close his eyes. When the ball was about to hit his mitt, the pitching coach with his eyes open was going to yell “now”, whereupon the catcher would squeeze his glove on the ball. Well, on the third try, the catcher caught the ball. The degree of difficulty of the exercise is incredible, but Greg Maddux had spent so many years internalizing the mechanics of his craft that he could effortlessly hit the catcher’s mitt. There probably are only a few pitchers in the long history of baseball who could match that exercise. I am not anywhere near that kind of skill in development, but that is my goal. When you get the mechanics of your craft to be intuition, it frees your mind to think about and solve larger problems. I have been fortunate to spend time with enough great developers to see this mastery in action.

Communication

For me, what is special about teaching is the commitment of thoughts to sound. Forcing something outside of my internal monologue always changes it, even if it is a small change. When I explain something, I often have to explain it multiple ways (this is telling of my communication skills, not of my apprentice’s learning skills). So, the more I am forced to answer questions on the spot, the better I get at quickly thinking through a question and giving a good answer. This dialogue is another one of the mental exercises which translates into my everyday development. It makes me a better pair programmer, better presenter, and better writer. Being able to accurately explain a problem and a solution using the language of software development is a very important tool in being a successful craftsman, and a tool that I fight uphill to improve upon. When I go to a talk at a conference and the presenter hits the problem and solution perfectly, it is a wonderful experience. The same is true when a team member can explain a solution in such intuitive terms that everyone gets it immediately.

Apprenticeship for me is as much about internalizing and expanding my own skill set as it is about expanding my apprentice’s.

Some Thoughts On Software Defects

by: paul | June 24th, 2008 | 2 comments »

Software defects are a part of software. This is a negative subject, but I don’t want to seem like the software I write is full of defects and bugs. This blog is addressing how I have seen teams turn a roadblock into a success. I have read and heard at conferences about teams who take small failures and create a culture of failure around it. Following are some examples of small failures I have seen and great successes built around them. Sometimes I see small failures as a path to larger positive culture changes.

I think it is safe to say all software that is used and sufficiently complex has defects. There are many reasons for the defects. Here are a few of the defect situations I have been in and how our team solved them.

I think the important part I learned after evaluating these is that resolution of these situation needs to be fast and high quality. They need to make the project better off at the end of their resolution. Success for the customer is the only true result of a project, and defects may not be the most ideal path, but they must lead there.

The speed is important, but it doesn’t mean I should rush a solution and throw it in as soon as possible. To me it means giving the defect the red carpet treatment. I am trying to capture craftsmanship in the face of adversity. Every project has its ups and its downs, and a craftsman will take pride in success through any obstacles. Instead of making defects a slippery slope downhill, they are one step back and we take two steps forward.

Bugs

Bugs are a part of every piece of software I have written. That statement sounds a lot worse than it is. I have worked on systems where the requirements are dramatically changed week to week (which can be pretty exciting). There are situations I didn’t take into account, or some behavior I didn’t imagine until a real user started hitting the system. Now, as a developer, I do more mental exercises and think thoroughly through my solutions as I get more experience. This has never made my code bug free. For that reason, my team needs to know how to deal with bugs (I am fairly certain I am not the only creator of bugs).

Here is a line from the Pragmatic Programmer book, “It doesn’t matter whether the bug is your fault or someone else’s. It is still your problem.”

So, the team has a bug list. We list out the bugs as a todo list in basecamp, so they are not so formal they can be forgotten about. Then we try to address them and work on new stories. This worked well enough until there was a big release coming up and our customer came back to us with a big list of bugs. We put them on the list and continued to fix them, as well as work on stories. They were getting completed, but there was never an empty bug list. Then, the customer (who can directly add/edit the bug list) started writing priorities to the bugs. This one is HIGH priority. This one is CRITICAL. This one is IMMEDIATE. I make the suggestion “We need some real tool to manage our bug list,” because I can’t fit all this in my head. There isn’t that much room up there and I need to use it wisely. One of my team members suggested maybe it wasn’t the craftsmanship way to have ANY bugs shipped. I was trying to solve the wrong end of the equation. So, the team lead put forth a no bugs policy that we all agreed with.

You can not pick up a new story unless the bug list is empty.

This made sense to me, but I had reservations about a small/insignificant bug taking priority over a story that is important. To date, this has not happened, and the bug list has stayed near no bugs. That doesn’t mean less bugs are found, it just means they are fixed, and the code is refactored to prevent a future occurrence. Most importantly, some tool to track bugs never made it into our system. That was an idea which would have desensitized the team mentality to bugs, whereas with our policy now we are very sensitive to the issue of bugs. Challenging the craftsmanship of the team members that buggy code is something you should take personally was the right choice. Bugs got a first class ticket to termination in our system.

Now, the definition of a bug versus a small feature enhancement is a fine line. I know I have failed to define it well, and that might contribute to what gets called a “bug”. Often times, the urgency in the customer takes up more mental space than me thinking through it, looking up the acceptance criteria for the story where it was implemented, and going back to the customer and saying, “No, that was clearly not a defined scenario, we are going to need a story to turn that button green.” Now the next time, it is more than turning a button green, but the precedent has already been set. All I have been able to do is to strike a balance based upon how much effort it would take to make the bug/feature enhancement work. If it is a lot of effort, I will double check the bug to make sure it is a bug. If it is, I fix it. If not, I will push back to the customer to write a story card.

Production Support

Once a system goes into production, support begins. Following along with one of Paul Graham’s ideas, we have the developers doing the production support. We are the ones who wrote the system and know the system the best. When I look at a production support request, I can not only solve it, but make sure it doesn’t happen again. Or if it does, make sure it is easy to correct.

So, during our first deployment of a system, a single team member stepped up as the “production support” developer. I don’t know if he embraced it or was cornered to it, but as a craftsman, he took the responsibility and ran with it. As further systems were released, he would sometimes be doing an entire day of production support. Production support can be a lot of debugging and fixing data, which can be fun, but more times than not is tedious and rhythmic. Often times when I saw a production support email, I would look to the “production support guy,” who could fix it in about half the time I could. This seems a lot like a silo to me. Everyone should be able to do production support on any system. I should have to, because it is a perspective of the system that is important to have.

In response to this, we came up with a system of triage. Each day of the week is assigned to a specific developer. If a support item comes up, it is the job of the triage developer to respond to the client/customer we are working on it. If it addressed to a specific person, they will inform them. Otherwise it is on the triage developer’s shoulders to fix the support request before they continue their work for the day. This ensures the client always has an open line of communication with a developer. An email never slips through and doesn’t get addressed. There is clear responsibility to who should be addressing the support item. I know the “production support” developer is in favor of this system. As well as the customer, they ask who the triage is for the day and have no qualms about interrupting their work, as they should.

Communication and Managing Expectations

Recently, I did some integration work with a third party vendor. They were developing their side of the integration at the same time as us. Not wanting to slow development and wait for their functionality, we decided to write a mock server and integrate with the host according to the spec from the third party vendor. We received a story from the customer for that and proceeded to make the client for the third party system calls. We finished our story. In the demo portion of the iteration planning meeting, we could only demo against our mock server. This caused some nervousness in the customer (rightly so). I replied, “Once their side of the system is done, we should be able to send our calls across.” Then we received three more similar stories, but different system calls. We did them, removed the duplication and felt really good about the job we did. The came their test server.

Nothing worked! There were all sorts of communication problems, questions about who implemented the system to what spec, and political questions. Despite us thinking we were in the right, the stories were signed and the customer said, “Well, you said this would work.” At first, I tried to communicate the reason why it didn’t work, and how we can move forward. We came to spend a lot of time on this, and the team felt the integration should be its own story. The customer pushed back, “Well, you said this would work.” There was some tension, because both sides were right. We didn’t believe it was our fault it didn’t work (neither did the customer), but we told them it would. Rather than let out the righteous indignation I was feeling, one of the team members mentioned.

“We should not have assured you it would work.”

That one line brought the real problem to the front for both sides. We didn’t know whether it would work or not, just that we wrote the right code to the specification we had at the time. That code by itself has no value to the customer without it working, though. Once that line was said, everyone in the room sat for a second, then understood. The expectation over defect versus behavior was out of sync. A little ownership over the defect was all we needed to ease the tension and move forward. It is unproductive to get stuck in a stalemate of expectations. When in doubt, the customer is always right.

Promises Promises

by: eric | May 17th, 2008 | 0 comments »

“Under Promise, Over Deliver” (origin unknown)

“How are you going to get a reputation as a miracle worker if you tell the Captain the actual amount of time it will take?!?!” Scotty on Star Trek

I used to think the first statement was a just a more cynical restatement of the second, which is just a con job. Tell the boss you can’t have it done until Tuesday, finish on Friday, play golf Monday morning and deliver Monday afternoon. Everybody wins right? Except it’s fundamentally dishonest. Lately I’ve come to realize I do the first one every day, and I hope never do the second.

I have three step-children and I rarely promise them anything. It’s not because I’m a horrible father, but because a promise is a fundamentally special thing. I promised my wife I’d stay with her until the end of time, now that’s a promise. If I promise I know damn well I will do what I said, and I can’t have excuses. Now I’m naturally a very busy and easily distracted person so I know that if I promise too much, I’ll deliver a lot of disappointment. Instead I say “maybe” because it’s the honest answer. There is a huge difference between “I promise” and “I’ll try”, and I doubt “I’ll do my best” would have been an acceptable answer on my wedding day.

So what the heck does this have to do with development? I was thinking about iterations, and how the stories taken on are really a promise to the customer, but we don’t always treat them that way. A lot of teams, including at times our own unfortunately, instead Over Promise and Under Deliver. It’s usually done with the best of intentions because the customer wants more stuff done. You know what? My kids want to go to Dunkin Dounuts tomorrow, but I don’t know if I can take them so I won’t make a promise. We should look at our iterations the same way. I’m not talking about padding estimates like Scotty does, but what I’m talking about is avoid the traps of wishful-thinking when estimating stories. Specifically three things I see all the time.

The talk down usually happens when one or two team-members are out of sync with the rest of the group on the high side, but can also happen when the team’s points cover a range from small to large. Higher estimates mean higher risk and yet the lower estimates usually win this “battle.” There are two kinds of ways team members (and sometimes customers) encourage other developers down from their estimates, one good and one bad. I’ll illustrate with two stories where I was out of step with the group.

Right after I joined 8th Light we had a store that involved converting text to base64. I was inexperienced with Ruby and hadn’t done this before, so my estimate was higher than the others. At some point somebody said, “Eric that’s a method that’s built into ruby, it’s one method” and I sheepishly shrank my estimate. Hey I used to be a C++ programmer, cut me some slack! The point is this time being talked down made perfect sense. I didn’t know something, somebody told me the answer, and we fixed it.

Much more recently we had a story that involved showing the difference between two objects in the database. In this case I was again much higher than the group. I explained I had no idea how we would do this in a way that would satisfy the customer, but the team thought using the Unix diff tool on the already existing XML Output would be fine. With something feeling wrong in my gut I reluctantly brought down my estimate. A few minutes later Micah and I started on development, and discovered the problem. A few small changes to a product resulted in four pages of indecipherable XML differences. The story was scrapped, fortunately quickly before any time was invested in it.

Now what was different between the two times? In the first there was a concrete and clear way that my estimate was wrong. Yea! In the second there was still an icky feeling in my gut, yet I budged. Why? Because I don’t want to hold up my team, I don’t want to look stupid, and most importantly I failed to articulate my concerns with the approach given. You see for years I worked with InstallShield Developer, and for a while now they’ve saved their file format for projects as XML. But when two people attempted to work on the same file, then merge, it was almost always a nightmare, and this was with tools that just did diffing like Araxis Merge. Our quickly done tool to solve an immediate business need had little chance of success, but I was uncomfortable saying so. The moral: Don’t let yourself be talked down unless you really feel talked down. The team wasn’t wrong for stating how they felt, I was wrong for failing to articulate the issues I had.

Occasionally as a team you really want to impress the customer, and they’re in a hurry. So maybe you take on a few extra points. I don’t feel this needs much explanation, don’t “hope” you can get it all done. Use your velocity, trust your estimates, and KNOW you’ll get it all done.

Sometimes your iteration feels just…off. You’ve taken on the same number of points as the previous iteration, but it feels in your gut like it’s too much. Now this is where the promise kicks in. Would you promise your loved ones something that in your gut you just didn’t feel like you could deilver? Than don’t do it to your customer. When the iteration feels ambitious try to put it in concrete terms, maybe you’ve been the victim of the “talk down.”

Remember a promise is a very important, even sacred, thing. It should not be taken on unless you are absolutely sure you can do it. Try saying to yourself before an iteration, “We promise to get all this done.” If that causes a shiver to go down your spine there’s a good chance you really hope you’ll get it all done, and maybe should take a bit off the board rather than be proven right later.

Agile Production Support: Final brush strokes

by: paul | February 18th, 2008 | 3 comments »

There is no perfect software. At least I have never seen it. Bugs and minor feature changes are indications people are using your software. Real users hit a system in ways that no control group can, and on non-critical applications, this is the best way to test your software. Let people use it and see what happens. This is goes in line with the agile philosophy of release early and often. Get your application out there as fast as you can, so you can mold the finishing touches around the real users experience rather than a faux-environment.

There is some conversation about what is and what is not a “bug” in the software world. That is not a conversation I would like to partake in here, so lets call both bugs, integration items, minor feature enhancements, and things that fall through the cracks of development tweaks. It doesn’t matter what the nature of origin is, these are all things that MUST get done.

After the release of one of our products, a load of tweaks came in from the customer. As proud craftsman, we decided tweaks were our responsibility, and we would take them on in addition to our normal iteration. So we started to do them, to the detriment of our iteration. We accomplished only about half of our iteration’s velocity.

The next iteration, much to our surprise, we were twice as busy with production support. This is about the time that a developer looses a little faith. What did we miss? Is this high quality software we are writing? So we lost even more velocity when it came to iteration 2 after the release. Also, the customers were now unable to accurately plan new features moving forward due to an unstable velocity.

It is so hard to predict or estimate production support and tweaks. However, we needed to be able to so that the production support didn’t leave such a footprint in the project. It felt and looked like we were not getting very much done, even though we were working harder than usual. It was the time being put into a vacuum and being unaccounted for that was troubling the project. It also had a negative effect on the morale of the team.

We came up with a card, we call the “Production Support Card.” The amount of the iteration’s velocity this card took up was calculated by the amount of time we spent on production support the previous iteration averaged with the amount of time allocated for that iteration(sound like a familiar formula?). It is added as a card to the next iteration. If the developers only spend 6 of the 10 points on production support, it is expected that they will complete 4 points worth of stories, which are automatically entered in the iteration. For the first iteration where it becomes apparent that we need a production support card, we set the point value of the card at 0 and track how much time we spend, bumping out of the iteration the least important stories if needed.

So, what does this tracking buy you, if you have to spend the same amount of time on tweaks? First, it allows transparency to the customer about what you are working on that week. When they see your normal velocity of 20 points turn into 5 points, they have a right to be worried. When you say, in a defeated voice “we were fixing bugs,” they also have a right to worry about the stability of the code you have been writing, even though this spike in minor changes to the application is a part of the normal process.

Second, it raises the moral of the team, because they are working towards a specific goal, to remove the production support cards from the iteration. Also, we get the satisfaction of maintaining a velocity in points, which is something we know so well it is hard to work without.

It takes a few iterations, and the team squeezes the life out of the production support card, putting you back on track. After those iterations, the footprint goes from sasquatch to mini-me.

It also helps the customer plan around production support. Their time lines and release dates are made from a projection of feature difficulty to development’s velocity. Over a long period of time, the velocity normalizes, and it hurts the projections to have hiccups. If you have production support data, you can predict about how much time around a release you will loose on the initial release of brand new development.

Peer Pressure

by: paul | January 18th, 2008 | 1 comments »

One of the famous studies on peer pressure was the Stanford prison experiment. A group of average people were selected to play either a prisoner or prisoner guard. As the participant became engrossed in the role, the peer pressure from other participants quickly degraded their moral compass. The small negative actions lead the groups to quickly fall into patterns of behavior which were unlike their own.

I see peer pressure work in the same manner for good all the time. Since software is written by teams, the software is often a reflection of how well the team works together more so than individual skills of the developers. When you have a group of developers who entice each other to do good work, the outcome can be great work.

Creating a culture of positive peer pressure is about doing lots of little things. Small positive actions will lead the team to create positive patterns of behavior.

Here are different techniques which have worked for different teams I have been a member.

  1. Name your team, not just your project. This gives me as a developer some self-identity as part of a team.

  2. Greet your team mates each day. We shake hands to show respect each day for each team member. We generally start and finish each day with a handshake. This can alleviate tense situations by itself, as personal contact often does. No chance to avoid a team member.

  3. Do some activity everyone enjoys. Anything from eating lunch together to playing a competitive game as a team. We have played basketball together. Being competitive with my team gives me pride in the team, win or loose. Get to know your team members.

  4. We keep a good supply of coffee, tea, snacks, and gum for each other as gifts. This act of giving to the team promotes the selflessness any team needs from its members top succeed. There are different levels of skill on a team, but each team member is important. It is difficult to write software for any project of magnitude without the full contribution of each member of the team.

  5. Switch pairs pairs often. When you work with everyone on the team, you feel closer to everyone on the team.

  6. Talk while you pair. Reading someone’s mind takes more effort than talking. Talking aloud also is a great way of brainstorming. Pair communication starts when words become sound waves.

These small things can improve the accountability and creativity to make a well functioning team. A happier team will become a creative and productive team. A team that has a strong sense of togetherness will lift each other up when needed. I find myself more willing to step up to daily challenges with the support of the team on my side. There is no place for apathy and complacency in a team which has pressure to succeed.

When the team succeeds, as positive teams often do, it becomes a group success and brings the entire team great pride. A team which pressures each other to do better can turn an average developer into a great developer.

That's Not Agile!

by: doug | August 5th, 2007 | 3 comments »

Removing the religion from software development

I had feared those words. I’d often been tempted to use them myself, but something told me I shouldn’t. As I sat in a planning game on a previous job, I heard the words. They still make me cringe. “We can’t do it that way. That’s not Agile.”

I’m a big fan of agile. I’ve long been convinced that the agile movement truly is uncovering ways to do software better. It’s revolutionizing the way that companies approach software. At 8th Light we’re using Agile to help us deliver the highest quality software possible to our clients. I wonder though, how exactly something can be classified as un-agile?

What is Agile anyway? Can it be measured? Can one thing really be more agile than another? If I had a yardstick and I was going to measure Agile, what would the markings be along the stick? What units would I use? ‘Points’ has already been taken, so maybe I should invent a new unit. I’ll call it the Agl. For every hour of pair programming an organization does it gets 10 Agls. Unit tests are worth 1 Agl each. Acceptance tests get 100 Agls. I’d use negative values too. For every page of documentation written, an organization looses 40 Agls, but the group running in iterations gets 1000 Agls. One week iterations are worth 2000.

The problem is that as a development organization adopts Agile and buys into various processes and practices, the temptation quickly grows to covert that development process into religion. “We can’t do code reviews, that’s not Agile!” “We don’t write documents, that not Agile!” What may start as genuine excitement and passion can quickly become religious dogma when those involved in the process lose sight of why they do what they do. Let me say that while I am a religious guy, I hate religion. Religion, to me, means action without thought: doing or saying something because that is the thing that you are supposed to say or do. I’d rather call what I have faith. Faith comes from beliefs or values held and turned into day-to-day living.

Since we are talking about religion, I thought I story from the Bible might be appropriate. Jesus and some friends were sitting down to eat when some super-religious folks showed up and started berating Jesus for letting his friends eat with dirty hands. These religious-types had established an elaborate ceremony for washing hands that had very little to do with removing bacteria. Jesus comes down hard on these guys for exchanging true principles for religious dogma. He responds by handing them the principle that does really matter. “Nothing outside a man can make him ‘unclean’ by going into him. Rather, it is what comes out of a man that makes him ‘unclean.’ ” (1) Here one of the most well-known religious leaders of all time shows his followers that it is the true principles that matter, not the religious practices or rules.

In software planning situations and day to day development we are faced with hundreds of little decisions about how to do our work. Should we throw this code out and start building the whole thing from scratch? Should we iteratively improve the code and slowly arrive at a better design? Do I write a test for this code? Should I pair with someone or just write this myself? When making these decisions we need guidance, something to help us understand if one thing is better than another. “Agile” is not that thing. Agile is just the label put on a whole spectrum of practices. Those guiding lights we need are principles. Principles are the domain-specific set of beliefs that an organization has adopted. They reflect what the organization values. I think it’s possible that many organizations get swept up in the excitement and freedom of agile practices that they skip this critical step of establishing the their principles. Kent Beck lays out a set of principles for extreme programming. Baby Steps, Failure, Quality, Redundancy, Opportunity, Flow, Reflections, Diversity, Improvement, Self-Similarity, Mutual Benefit, Economics, and Humanity(2) help direct an organization when it is trying to figure out the how of software development. Whenever I’ve heard Kent speak, he always comes back to the principles and values behind the practices in extreme programming. UncleBob has established a great set of principles that help us discuss and qualify designs. The Single Responsibility Principle, the Open-Closed Principle, the Don’t Repeat Yourself Principle(3), and others are guiding lights for design decisions. These give teams concrete evaluators that keep design discussions productive and prevent them from deteriorating into contests of dogma. Alistair Cockburn writes about 7 properties in Crystal Clear that can be translated into principles: Frequent Delivery, Reflective Improvement, Osmotic Communication, Personal Safety, Focus, East Access to Expert Users, Automated Tests, Configuration Management, and Frequent Integration (4). I don’t want to delve too deeply into these principles here, but an organization in the process of adopting agile should. Each of these manifesto-signing authors have explained these principles wonderfully in their books.

At issue in my planning meeting was whether or not to require a certain feature in a third party library for which we are shopping. At the time, we didn’t have a need for this feature, but we anticipated that it may show up an upcoming story. The person who spoke up saying “That’s Not Agile”” was really referencing the XP value of simplicity. “Solve today’s problems today and tomorrow’s problems tomorrow.”(2) This would suggest that one shouldn’t take on additional complexity until it is needed. However, when purchasing a third party library, perhaps the principle of Economics might suggest that paying a little more for this library today will save a lot of time and money later and potentially avoid purchasing the library twice. Which is the right decision? I don’t know, but after having agreed on the principles that guide our decisions, we can have the conversations around those principles and pick a way forward.

An organization transitioning to some flavor of agile ought to first clarify what its organization’s principles are. Read Beck or Martin or Cockburn or your favorite Agile author and choose the principles that you want to live by. Second, make the principles visible. Put them up on a wall. Have meetings where team members present a principle. Refer to them as you pair. Write about them, read about them, explore them. At 8th Light, we’ve put them on our website. Revisit them when starting a new project. If you are working with a consultant, ask them to take you through a values and principles exercise. If you are a consultant, please don’t miss this critical part of transitioning to Agile. Making your principles part of the every day vernacular of your organization will take you to a place where design and planning discussions stay productive and you’ll hopefully never hear “That’s not Agile!” again.

End Notes:
1) Mark 7:1-16
2) Beck, Kent. Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional. 2004.
3) Martin, Robert C. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. 2002.
4) Cockburn, Alistar. Crystal Clear: A Human-Powered Methodology for Small Teams Addison-Wesley Professional. 2004.

Shake Things Up

by: doug | July 19th, 2007 | 0 comments »

The most widespread and common greeting in the American culture is the handshake. Handshakes are shared between anyone meeting for the first time, to finalize a business deal, and to end a conversation. I spend a good deal of time around 2nd and 3rd generation Korean-Americans. In Korean culture, like many Asian cultures, the handshake is replaced by bowing. In these transitional immigrant generations, the bow and the handshake have been merged into one awkward action. I was recently walking through the reception line at the wedding of 2 second generation Korean-Americans and I went to greet the 1st generation parents. I was going to try to be respectful and offer a bow instead of a handshake, but just as I began to bend, a large hand was thrust out in front of me. I felt myself lucky that I didn’t end up with the guys finger in my nose.

One of the things I immediately noticed as I began working with the craftsmen at 8th Light is that everyday I walked into the office, every member of the team shook my hand. As each team member left for the day, he shook the hand of everyone who was left. I expect this on the first day, as you always shake hands with everyone on your first day. On the second day, I thought maybe they had all forgotten that they met me yesterday. As I realized that this would continue, It really made me start thinking.

As I went to work with another team for a little while I came to really miss the handshakes. I’d walk in the morning and maybe get an eyebrow flash from my teammates. A “Hello” would come if I was really lucky. I decided enough was enough, so I just started shaking hands. At first, I got some really weird looks and was left hanging a few times. The looks seem to ask “Why are you shaking my hand, we see each other every day.” But slowly it started to catch on. My teammates began to expect a handshake from me at the start and end of each day.

Here’s what I think these bookend handshakes do for a team. First, believe it or not, a handshake becomes an intimate gesture. It communicates genuine care and concern for each other. To me it’s a physical expression of the XP value of Humanity.

Second, it communicates respect. Sometimes design and project discussion can get very heated, especially if you are working with a passionate group of people. If your days begin and end with a handshake, everyday is bookended by a statement of mutual respect. There is a proverb that exhorts people to “Not let the sun go down on your anger.” That handshake is a way to let go any residual anger from the day and commit the next to dealing with each other with respect.

Third, It’s an honest statement about the hours you are working and the time you are putting in on the project. In a handshake-free environment, if I’ve had to leave the office early, I’d usually try to sneak out without anyone noticing. At the time I was in an office culture that promoted flexible hours, but you always felt like people were watching you to make sure you were still putting in your hours. I always put my time in, but because I sometimes played with my schedule quite a bit, I was always afraid that someone would perceive my time poorly. When an handshake begins and ends your day, you are being direct and up front about your time. You are communicating at the start of the day “I’m here, I’m ready to work” and at the end of the day “I’m gone, my day is over.” There are no apologies, no sneaking in or out, and no elaborate time-tracking system. Your teammates trust that you are working as much as you should be and you are not likely to try and cheat you company or your team out of your time week-to-week.

Try it in your team. It’s a morale boosting behavior that will cost a team nothing to implement, but will be one baby step to improving the strength and productivity of the team.

Something new, every day

by: eric | June 26th, 2007 | 0 comments »

Last December I went to to StarEast in Orlando because my fiancee is a tester and I well, I like sun. While there I picked up the book Practices of an Agile Developer and was particularly struck by the practice to keep a “Solutions Log.” The way a solutions log works is simple. Every time you find a solution to a problem you write it down, and later when you are confronted by a similar problem you have a reference. “Gee Whiz what a great idea!” I thought to myself, because I think to myself like Beaver Cleaver, “this way when Jim asks me about that bug I solved two weeks ago, I’ll know exactly what to tell him, instead of saying “uhhh, err, yeah I sorta kinda remember…” It really was an amazing revelation, seeing as how I hadn’t met Jim yet.

genius_hat Then I got home and subscribed to Venkat’s blog where he recommended TiddlyWiki for keeping this list. If you’re unfamiliar with TiddlyWiki it’s an extremely cool browser-based personal note-taking tool that works entirely via JavaScript and CSS. You fire up your personal version of the html file, double click, and viola! there you have a note saved into the very document. Best of all it’s searchable even via regular expressions and plain text. With this tool I was gonna be a solution mastermind! People will ask me for that bug I fixed 14 years ago and I’ll be right there with my genius hat on and everything. You do have a genius hat don’t you?

dunce_cap How did it work out? Roughly 18 months later I have a whopping… 16 solutions, most of them written in the first week. You know what I learned from this? I suck at keeping a solutions list. The thing is I have no idea something is a solution to a recurring problem, until I come upon it a second time! What I need is a way to psychically determine what the solutions I’m going to need in the future are, and identify them. Um….

I’ve decided on a different option, which I think fits in well with the craftsmanship approach of perpetual learning. Since joining 8th Light I’ve been lucky enough to learn enormous amounts in a short amount of time, with more on the way, but of course none of this is in my solutions list. So instead of catching the realization that something is a solution, I’m going to write it all down. I’ve created a new list, and instead of calling it a Solutions List, it’s my LearnANewThingEveryDay list. Every day I’m obligated to write a new note with something I’d learned that day. If a day goes by and I haven’t learned something, I have to go learn something. I’ll read a book, find a great blog posting, try out a coding exercise, whatever. For example today I have written down some things I didn’t know about routing in rails. Mundane stuff that people more experienced with routing already new such as the :path_prefix parameter. What would be an otherwise fruitless day debugging now has a few little things I’ve learned from it. Will I ever search for that item? I don’t know - but the point is I can, so when Jim asks me how to get eric/is/the/coolest/blogger in front of all his links, I won’t stand there scratching my head.

Pair Me Up

by: paul | June 14th, 2007 | 15 comments »

I am a better pair than solo developer. For me, software is a collaborative art from the start to the end. Starting from the beginning of a project, where the developers need to collaborate with the customer s and stakeholders of the project to learn about the business domain. Then working with the project manager for sorting priorities and deadlines to make the business goals realizable in the fastest amount of time. Also development is collaboration, via pair programming, to produce a dialog between the developers on their vision of the implementation of this code. The last part, pair programming, is what I would like to focus on.

Having a pair has the traditional advantages of keeping disciplined and sharing the knowledge base. That is a starting point, but pairing is quintessentially important to my process due to the diversity it provides. A diversity of approach and implementation provide me with enough to perform at a highly creative and expressive manner.

Since you are not driving the keyboard and control of the computer, there is more time for contemplating code you wrote and direction you are moving. Most of my good ideas come from the time when someone else is typing. Since I was just working on the practical, I have my head wrapped around the code, and since I am not responsible for typing, I can reflect in the abstract.

I have heard many places that a benefit of test driven development is that the tests force you to design the API of the objects you are using as someone would use them. Well, pair programming, in compliment with programming ping-pong, forces your code to be clean. When you write a test, it isn’t you that makes it pass, so you have to think with expression and intent in mind. So, you end up writing the test FOR your pair. It becomes a form of writing, not just coding.

Sometimes, the test needs to be explained. While explaining something to a pair, your test must hold up your own arguments. Often times when I come to explain something I just wrote, I think of a better way to do it. Explanation is the best form of validating you understand where you are going well.

Also, pairing is how I learned most of my developer personality. Taking bits and pieces of the traits of my pairs through years of pairing. My style is a composite of pairing with various mentors and peers of mine. It has shown me how people approach this craft.

Lost in Portland, and Thinking

by: eric | May 20th, 2007 | 0 comments »

Did I say I was tired yesterday? That wasn’t tired, this is tired. I’m currently training for the marathon, and today I was scheduled for a 13 mile run. Sadly marathon training does not wait for RailsConf so I was up at five this morning, viewing the fair city of Portland. Say what you will about running, but it’s a great way to see a new city.

It’s also a great way to get lost. I used the great website at USA track and field where people post their runs in order to find a place to go and promptly wrote down a street name incorrectly. I ended up wandering around Portland’s lovely Willamette river, which fortunately provides a great landmark for a poor lost tourist. This led to running, and running, and running…and finally a Runners High.

Runners High is a phenomenon cause by your brain releasing endorphins, as a defense mechanism against the way your body feels. When I run my brain feels extremely active, and jumps from topic to topic making associations, breaking down problems, etc. It’s not unheard of for me to fix a bug I’d been struggling with while on a run, in a sudden burst of insight. Today, when I wasn’t wondering where the hell I was, I started thinking about quite a few things one of which is related to the new IDE’s being developed and the barrier to entry on Rails. Bear with me because this is a little out there, and I haven’t quite figured out how to articulate the concepts.

Right now Ruby and Rails are still strange and unusual things to most developers. When introduced to the language they want an IDE, and upon hearing there is no visual debugger or that they have to use Textmate, Eclipse or god-forbid emacs they turn away. They stick with Java or C++ and wizards and comfortable development, and will wait until they need to use Ruby.

Then one day their boss hears about Rails. They tell the developer, ‘you should be using this!’ and so he goes and he gets an IDE, real slick one with lot’s of bells and whistles. He goes to generate a model - only he doesn’t use script/generate. He uses a wizard, he sees he can add his methods and data members right there, so he does. Test? What test? Then he goes to the controller and has his controller manipulate the data all day, and develops a view in a WYSIWYG editor. He spends all day in the debugger, and his methods get bigger and bigger. Of course that’s no big deal, because he uses cold folding to hide their size. Then testers write Test::Unit code to test his code, and he’s done, because developers don’t test. Meanwhile we’ve all left Ruby because, “so much of the code is crap.” Haven’t we done this cycle before?

Chad Fowler described us as arrogant in the introduction, and clearly if you look above we are. I say we because nobody reading this had a problem with my rant, so you’re just as arrogant as I am. Caught you. We think we’re smarter than everybody else don’t we? Actually I don’t and most of you probably don’t either. I just know that there is a right and wrong way to do things, and so does Rails. That’s why it’s so opinionated. An attendee, Jack Canty, put it better than I can by saying “Rails is opinionated, and this takes away those opinions.”

So how do we fix it? Well let me steal some of Micah’s DSL thunder by using an analogy I thought of while running. It’s morning, and you want a coffee. So you go to a certain ubiquitous chain and say, “I’d like a big coffee please,” only said ubiquitous chain doesn’t have big. They have Tall, Grande and Venti. If you do this there will be a noticeable pause while the guy behind the counter takes a second to think about what you just said. He’s not a moron, take off his green smock and he knows what a big coffee is, but he’s got to translate it. What’s big - is it grande? Venti? That’s because you’re not speaking his language. You eventually do get your coffee, because he can figure out what you mean, but it takes just a little bit longer. While you wait in line you hear other people say, “I’ll have a grande half-caf no-foam latte,” and the guy behind the counter immediately repeats it. Eventually you learn the language they speak, and you get your coffee just a little bit faster. You’ve adapted to the idioms of the coffee shop, and you’ve been rewarded for it.

So what the heck does that have to do with code? I kind of gave it away by using the phrase idioms, didn’t I? Well let’s say you’re a C++ programmer and you start on Ruby. You don’t write Unit Tests, which despite what we sometimes think most developers do NOT do, and you sit down to iterate through an array. So you write:

  1. index = 0
  2. while index < array.length do
  3. puts index
  4. end

Much like ordering a big coffee at the Green Angel, that will work, but it’s completely incorrect. It’s not speaking Ruby even if it’s in the Ruby language, and unfortunately I believe that if we do not work hard to enforce and teach the best practices of the Rails and Ruby ways, we will witness this kind of thing propagated. I’ve done the C++ without test thing and lived in the debugger, and it drove me nuts. Unfortunately many developers don’t think anything is wrong with that. If they did they’d be here already. That’s what programming is to them. The good news is that we are the early adopters, and when they come around they will adapt to our rules but only if we make them. Remember what I said about the pause at Starbucks? Well the code above won’t pause. Ruby will execute it just as nicely as anything else, and maybe it shouldn’t, I’m not sure. What I do know is that the IDE’s now being created should not be catering to the developer that wants to do the things the way they’ve always done them. Instead of opening ‘choices’ up and making things ‘easier’, our IDEs should enforce the opinions of Rails. You see the late adopters aren’t lazy, or stupid, they’re just being rewarded improperly. If it’s easy to make a model without tests, they’ll make one, even if they are hurt by it later on. They’ll even stay until 1 AM to debug it, and their boss will think ‘gosh this Rails thing isn’t so great after all, thank God my programmers are so dedicated.’ Fortunately we control this. There’s a reason the IDE makers are here, and that’s because they know that late adopters ask the early adopters what they use. Tell the IDE makers that you want an IDE that does not allow bad habits. I want an IDE that is integrated with subversion, but I also want it to yell at me if I have untested code, and run ZenTest. If it gives me a wizard the first question it should ask is “what is the name of the test?.” Instead of code folding to hide bad code, it should identify refactoring opportunities. Finally, I’m not sure I even want a debugger. Debugging sucks, and it’s a crutch. I can test behavior rather than step through it and look at it. I realize people do want debuggers, I just worry for the day when Rails code can’t be properly understood without stepping through it.

Tell the IDE developers that you want an IDE that helps create good code, not easy code. If they don’t do that, then when developers ask you what you use say emacs. If the developer still turns away, we probably aren’t losing much.

Hello from RailsConf

by: eric | May 17th, 2007 | 0 comments »

Of course if you’re reading this you’re probably at RailsConf so hello from here. I’m right next to you actually, to your right. Yep that’s me, hi. There’s a coffee stain on your shirt.

I plan to blog as much as possible from here, and hopefully bring a little of the experience back home to those of you that couldn’t make it. I just came out of my first tutorial, “your first day on JRuby on Rails”, and found it quite enjoyable. Admittedly we’ve been playing with JRuby for a little while know here at 8th Light, so much of it was stuff I already knew, but it was great to talk to Charles Nutter and get some of my questions answered directly. Some highlights:

In other news the Portland Conference center is really nice, with pretty good wireless network connections. One thing I’d ask for would be more tables outside the ballrooms, as there are only about 6 and a lot of people have their Macs open on the floor. Speaking of which I’ve never been anywhere that the Mac so dominated. 80-90% of the people here are carrying MacBooks.

Now if you’ll excuse me, I’m hungry.

Clean as You Code

by: micah | January 29th, 2007 | 0 comments »

In my younger days I was a Line Cook at the Olive Garden. In case you’ve never worked in the food industry, Line Cooks are the guys putting meals together as fast as customers order them. At times, it’s nearly impossible to keep up.

Among the most fundamental of the Line Cook’s principles was Clean as you go. I can remember clearly the manager walking regally down the line chanting, “Clean as you go Javier. Clean as you go Micah. Clean as you go Brian.” Cooks would remind each other from time to time too, “Clean as you go!”.

As you’re realizing, it’s import to keep your station clean when you’re a cook. Keeping things clean is not easy. Food gets EVERYWHERE when you’re putting together hundreds of meals an hour. Why is it important to keep it clean? Simple. When your station is dirty, the system breaks down and it slows you down. Utensils are dirty or missing, ingredients get mixed together, cooking surfaces are soiled… Combine this with all the fire, boiling water, and sharp knives, it’s dangerous too! Worse, other cooks are not able to help out. Uncleanliness on the line is a vicious cycle with positive feedback. Every experienced cook keeps their station spotless at all times and unexperienced cooks learn fast.

Dirtiness is a sign of trouble too. Let’s say that it’s the middle of a dinner rush. You look down the line and notice that Javier’s station is becoming cluttered. It’s near certainty that in five minutes Javier’s system will break down. Food will be burnt, orders will get lost, and servers will get vocal. Don’t get servers mad! Line Cooks work as a team though. So when you see that Javier’s station is getting cluttered, you jump over and give Javier a hand every moment you can spare.

This principle, “Clean as you go”, is well applied to software, “Clean as you code”. The analogy is fairly straight forward. Although I’ve applied the principle to software for years, it was only recently that I recalled the mantra “Clean as you go”. I’m sure my teammates will soon grow tired of hearing me chant… “Clean as you code!”

Craftsmen are like Babelfish

by: micah | October 2nd, 2006 | 2 comments »

Show me a software craftsmen and I’ll show you someone who can program in any language if they had to.

From time to time I meet developers who define themselves by the one and only programming language they know…. “I’m a Java developer”, “I’m a .NET developer”. It’s deplorable. I suspect such people don’t care much for their career.

Better are developers who can whip up code in multiple languages. Web developers, for example, often have to code in javascript in addition to the primary language whether it be Ruby, Java, or .NET. That’s respectable. Yet, many of these developers are intimidated by the notion of programming in some other language like C or C++. It’s a shame. There’s lot’s to learn from unfamiliar languages.

A Craftsman will not shy away from using the right language for the job. They understand that the act of programming is fundamentally the same despite the language being used. A craftsman is not intimidated by unfamiliar languages. When they’re confronted with a new language, they’ll learn it. After all, new programming languages are easy to learn.

Software Apprenticeship

by: micah | September 7th, 2006 | 0 comments »

David Hoover asked me a few questions about my experiences as a software apprentice. I was happy to answer his questions and pleased to hear that he’s writing a book on the topic.

What is Software Apprenticeship?

Software apprenticeship is path for learning to become a quality software engineer. A software apprentice learns to write code by working with people people who already know how to write code and are good at it.

It’s also an attitude. People who practice the software craft are on a journey of continual learning. There is no piece of paper that deems a craftsman worthy. A craftsman qualifies himself by demonstrating his skills.

I’d argue that any great software developer has been through an apprenticeship stage at one point or another.

How did I hear about Software Apprenticeship?

I saw my father reading a book titled Software Craftsmanship by Pete McBreen. This was shortly after I finished an unsatisfying 5 years in college. I was also knee deep in my apprenticeship, though I didn’t call it that at the time. I read the book and fell in love with the idea that software is a craft. For several years of my life I practiced martial arts and the model for growth in Jujitsu is very similar to that of software craftsmanship. So the concepts were not new to me but seeing software in this light clarified a few things…

No wonder I was so unsettled with my college education… That’s not how you’re supposed to learn software. Of the dozens of classes I took in earning my Computer Science degree, only 3 classes involved writing code. Crazy huh? And even though I could write programs after I graduated, I didn’t know the first thing about writing real software. A lot of good college did me! It was working with the great people at Object Mentor, especially my father, that truly taught me to code.

Not long after I read Pete’s book, Ken Aurer invited me to a Software Apprenticeship summit. There, several pioneers in the software craftsmanship movement got together to share experiences. I learned a great deal but what I took away from that summit was the comfort that there were lots of people who believed in the craftsmanship model. It was only a matter of time before the rest of the industry caught on.

Where am I in my journey?

For those new to the craftsmanship model there are three stages: apprentice, journeyman, and master craftsman. I’m well on my journey as a journeyman. I work on a variety of software projects, I teach, I consult, and I learn more about software every day. And to take this entry full circle, I help other budding software apprentices get started on their journey by leading Object Mentor’s apprenticeship program every summer.

Wed, 22 Jun 2005 21:53:29, David Chelimsky, hands on I had the good fortune to attend a graduation at which Deborah Meier spoke. Ms. Meier is an innovator and educator who founded a grade school at which kids of varying ages/grades work in the same classroom. She described the inspiration for this, talking about how schools USED to be when we (in the US) were a more agrarian society. There were two comments she made that seem relevant in the context of this discussion. One was that you would never choose to take a tennis class in which students sat around talking about tennis and then, one special day, the teacher brought in an actual tennis ball and passed it around so everyone could hold it and see what it felt like.

The other was the fact that in days of school gone by there were many experts and a few novices. The 7 year olds helped the 6 year olds. The 8 year olds helped the 7 and the 6 year olds. Etc, etc. Many experts and few novices - not one expert responsible for 30 novices. This made me think of the blacksmith analogy that permeates the Craftsmanship book.

Wed, 22 Jun 2005 01:53:36, KelleyHarris, ?Finding mentors for mid-career people? Great article Micah. Any suggestions for mid-career people looking to find mentors, full-time, part-time, or remote? Seems like there is room for a service connecting people. There is also room for a service providing object mentoring post OM courses.

There is no piece of paper that deems a craftsman worthy. A craftsman qualifies himself by demonstrating his skills. As people look for new jobs, what would be some good ways of demonstrating skills, at the resume & interview stage?

Any suggestions on open-source projects with great OO TDD code?

Mon, 20 Jun 2005 08:51:34, George Jensen, My Story I guess my story would be different from Micah’s in that, Higher Ed was good for a few seasons, but by no means did I expect to begin learning a craft there. If the above statement were a microcosm for Liberal Arts experience, we might assume it a bankrupt philosophy. This is the impression Micah might give off. After spending a week with Uncle Bob with Java immersion (2002), I can say I was one of those “Masters Level” students who knew nothing of good programming practices. I studied History in undergrad, and Information Science in Post-grad; but I continue to be pulled by the curious efforts Uncle Bob uses to hown the craft of programming, and his old-factory style of learning programming as a “craftmanship”.

I ask daily: With all the altruistic spirits of academia stuffed down our modern minds, why is it so refreshing to hear the obscure rant of Uncle Bob (and others) toting this old-factory campaign about “craftmanship” as a life goal?

Fri, 17 Jun 2005 10:02:01, Uncle Bob, Things have indeed changed. Keith, Things have indeed changed; at least in some sectors. A couple of years ago I brought in an intern who was in a CS masters program. This inidividual simply could not write code, nor had they been taught to write code. I was flabbergasted. I’ve poked around a bit since and have found that, at least at some schools, it is possible to acquire a BSCS, and even an MSCS, without ever having to write a line of code. Incredible!

Thu, 16 Jun 2005 11:22:16, Patrick Morrison, Things were different, but not necessarily better I must’ve gone to college around the same time Keith Ray did, as I can’t think of a CS course I took that didn’t involve at least some programming. But, with one exception (Principles of Software Engineering), every single course required the student to work alone… this is the antithesis of the craftsmanship model, and I’m sure it stunted my growth as a practicioner.

Thu, 16 Jun 2005 09:50:09, keith ray, things have changed When I went to college and got a computer science degree, just about every computer science class required writing code. The only one that didn’t was the one where we designed a CPU. Those who were in computer engineering rather than computer science had a sequel to that course: they had to implement their cpu design.

We programmed in FORTRAN, Pascal, C, 68000 assembler, and COBOL, and the “survey of computer languages” course had us writing short programs in APL, LISP, SNOBOL, and other some other languages.

Jack and Jill

by: micah | September 7th, 2006 | 0 comments »

Once upon a time there live a young girl named Jill and her next door neighbor Jack. Perhaps you’ve heard of them. When Jack and Jill were about 5 years old they both desperately wanted to learn how to ride a bike. Jill’s father, being a practical man, bought Jill a nice child-size bike and took Jill outside to practice riding the bike every chance he got. Jill’s dad would hold Jill up right and move with her while she pedalled. Within a few days Jill was able to ride for moments at a time without her father’s support. After another day, Jill could ride her bike all by herself.

Now Jack’s family was a bit more rigorous. Jack’s father thought it important that Jack have a solid understanding of bike riding and the science behind it before he start riding a bike. So instead of a bike, Jake’s dad bought various books on physics and cycling history. For weeks Jack learned from his father much about kinetic and potential energy. He gained an understanding for gyroscopic forces and much, much more. After about a month, Jack knew everything there was to know about bike riding. It was at this point that Jack’s dad bought a bicycle for Jack. Jack proudly mounted the bike and promptly fell off. He mounted the bike again, peddling slowly and ended up in another painful fall. Meanwhile Jill was effortlessly riding her bike around block, feeling bad for her friend Jack.

Later in life both Jack and Jill graduated high school and wanted nothing more than to become software developers. Jack, following societal protocol, applied to a prestigious university was accepted to the computer science (CS) program. At the onset of his first semester, Jack was mildly disappointed to find that CS program alloted only one class in the first semester that had anything to do with computers. This class was called “Computer Algorithms I” and involved no programming what so ever. Other than this Jack learned Calculus, Philosophy, and other peripheral classes… lots of classes that had nothing to do with computers.

Meanwhile Jill moved to Chicago to become an apprentice for a renowned software company. On day 1 Jill was learning to write Python code as she worked side by side with an expert programmer. Like a kid in a candy store, Jill was nearly overwhelmed with all the software knowledge and learning experiences surrounding her. It was great!

After a few years, Jack had graduated. With all the calculus, differential equations, spanish, number theory, and computer architecture classes, there was no doubt that Jack was a full fledged CS graduate. It didn’t matter that he had only written a couple hundred lines of code by this time… He had a bachelor’s degree! Jack soon landed a programming job in the IT department of a large company. On his first day Jack was introduced to the project he’d work on. He met the team, found his desk and was anxious to get started. Later that day his project manager walked in with a thick binder titled “Data Model/Object Model” and said “Read this by next week”.

At around the same time Jill already knew how to program in Python, Java, C#, and had dabbled in a few other languages as well. Object Orientated principles and pattern came naturally to Jill since she had used them extensively on a daily basis. Having worked on a few successful projects she knew a bit about managing projects and what it takes to get them done. No doubt about it, Jill was a software developer to be reckoned with.

Sat, 22 Oct 2005 18:35:39, Sy, How much shallower you could be? Jill you mentioned probably one of those who think programming is learning syntax of many languages, assimilating technologies and spending rest of the life buidling “nigh performance”, “scalable”, “enterprise” apps for naive users to let them do data entry. Clearly you haven’t solved demanding problems in programming. Try this: write a program to find the contingeous set of elements in int array whoes sum is maximum. This problem comes up in image processing and most “programmers” (i.e. VB, C#, Java hero types) would have difficult time to come up with anything efficient. If you do come up with something, can you analyse it’s performance on asymptotic scale? About learning calculus, have you (or are you able to) write cool simulations (like those in billiords game)? Do you know how and why Google’s BigTable structure works? Have you ever tried to write 3D rendering for choosen vantage point? Can you look at kernal code and tell me why it must manage threads in some specific way? Writing code in high level language for data entry screens is easy. Creating cool algorithms is hard. And if you didn’t took a courses in CS, you probably even wouldn’t know what Big O notation means or how Hashtable works internally or why Trie DS is vastly more efficient for search.

Vast majority of self tought programmers end up in mediocre jobs in big company and climb up the ledder to become a dev lead or manager in 4 years while their mates are still trieng to graduate with CS major. They might joke about CS majors wasting their years but there is stark diffrence in their capabilities and where they would finally end up. People who could answer above questions would probably be working on ground breaking projects at Google or MS or Nasa while people who can’t would be still trieng to fix the bugs in their trivial so called enterpirse apps.

Discloser: I’m not CS major!! I leard this truth hard way and wasting my years developing software for insurance and financial companies for 8 years. Yeah, I’m now senior programmer, make big bucks but had been rejected twice by MS and once by Google.

Mon, 17 Oct 2005 13:13:57, Alex Mueller, A true education never ends I understand the alluded to point of this story. People learn in many different ways, and what works for one may not work for another. However, I do have a few comments on the importance of education, and by education, I mean the underlying desire that motivates individuals to pursue knowledge.

The point of this story is that traditional education taught in schools will not guarantee understanding, competence, and ability. Individuals will retain different aspects of an education. A true student is never finished learning. A true education extends beyond the classroom.

A traditional education conveys to me these things. One is the ability to learn new concepts, and when required, to regurgitate these. The most visible result of education is the ability of the individual to complete a project from start to finish, essentially, doing what needs to be done, when it ought to be done, regardless of whether they like it. In the world outside of the classroom, this is a valuable lesson to learn. Another lesson is balancing work and life.

Achieving the degree is an accomplishment worthy of accolades, because it is not easy. I do not want this Jack and Jill story to belittle education. For those students out there who pursue education in addition to working, tending to families, and dedicating their time to outside activities, these individuals represent the hard work and dedication needed for success. A lesson learned the hard way.

The individual is responsible for their drive to succeed, and this cannot be taught. Ultimately it is up to them to pave their own roads. Jill appears to already be successful, but this does not make her approach any more or less appropriate. Jack’s education alone will not suffice, he needs to apply it.

This story compares Jill to Jack, at a time when Jill has been working in the industry for some time, and Jack has just begun a new job. Give Jack some time before condemning him. Education is perhaps better left to the individual to decide which path is more suitable.

Sun, 16 Oct 2005 22:57:53, someone, JackAndJill Is it any wonder Jill Advanced much faster than Jack (When jack, wanting to be a programmer, took Computer science related courses, instead of Software Engineering ?!) Did everyone here miss that point ?

Anyhow, Education is important, school is not. I know several people, who to begin with in software / computer fields were H.S. drop outs. This is not to say, I would advise anyone to do so, because I would not. However each individual needs to find thier own path in life. If you speak to anyone in the computer field, and asked if they would hire someone with experience, or someone with a degree, well, any one of you in the field knows the answer to this.

From personal experience I would say a well rounded education would/could help in any situation, but as always there are exceptions to every ‘rule’.

Sun, 7 Aug 2005 15:17:49, Bill Caputo, There is an implied premise here that is the real problem… …and that is the increasing emphasis on College as: “Preparation for Career.” In so doing, it has also become the new high school, so now adulthood is reached after college. It wasn’t like this 200 years ago. Older descriptions of college seem to describe a place where one “Prepares for Life” by learning about it, and learning how to learn about it. The so-called classical education wasn’t practical, but it was essential for taking one’s place in “learned society.” An unintended consequence of extending education to everyone? (it was once the purview of the wealthy only, some guy named Jefferson among others were big on changing that. My take on this then, is that college then apprenticeship might be the best path of all – if only the colleges didn’t cost a fortune, and only attract people because they might need to “get a job someday.”

All I know for sure is that I didn’t study computers in college, but my education serves me very well everyday I go to work with them.

Thu, 14 Jul 2005 14:23:53, Vishal Shah (vishalshah.org), Never reason from one example/case/situation Picking an apple from a lot of 10,000 will not say anything about a lot. Picking an example of this->John and this->Jill gives a person nothing to reason/imply/believe. Besides we don’t need just on kind of apples. We need a variety of them that suits different tastes and recipes. Every person is unique in its own and this idea can not be generalized or “reckoned”.

This post hence says nothing to me. In fact I am worried as it might send a wrong statement to readers. Instead here is something that you can rely on - “Believe in yourself”

BTW. At the end of day, despite Jill being a great software developer might not be as happy as Jack because he got a wonderful wife whom he met in college. While Jill never found someone she could truly love because she did not have a chance to find the opposite type. She also missed the chance of having a college life, which once lost can never be regained. To gain something you have to loose something and it is upto that particular person to decide what he/she would rather loose.

Thu, 14 Jul 2005 09:45:02, Suresh V., And what happens when it is time to redesign the bike…

Sat, 18 Jun 2005 02:03:43, bookie, heres another perspective in my experience, there are two kinds of ppl, people who build things versus pppl who build tools. both kind of people are required in any domain to function well. However, lets not typecast one over the other, maybe jack might become a toolmaker and be no good at building anything. maybe jack might become someone who proves p = np. maybe jill will write really bad c^n algorithms.

point being fitting people to their jobs is as important.

Fri, 17 Jun 2005 09:50:06, Uncle Bob., A Learning Attitude. At Object Mentor we practice the apprenticeship model. Young bright people from 16 years and up, are encouraged to work on real projects with real developers, in an atmosphere of learning. We teach them a lot, and (if they have the hunger) they learn a lot. There is no better way to learn a craft, like software engineering, than sitting with a master or a journeyman.

That being said, learning must be broad. We would be doing a huge disservice to our apprenctices if we channeled them to learn nothing but the craft of software. We would also be doing a huge disservice to ourselves. Learning, regardless of ”’what”’ you are learning, is beneficial to everything else you have learned. Your career as a software engineer will be enhanced if you learn a little American History. You will be able to understand the company you work in much better if you study a little political science. You’ll have a better perspective on life, including your employment and your carreer, if you study some Philosophy. You’ll have a better perspective on just about everything if you study a little Astronomy and Cosmology .

So, whether it be college, reading, mentoring, or apprenticeship, the main thing is the Learn.

Fri, 17 Jun 2005 08:13:51, Mohan K Jadhav, Though I have graduated in an Engineering Major other than the Computer Science, I would say that it is not the college degrees that would help one to acquire the skills. It is the learning attitude that matters most. Of course, a formal and a structured education would always help in understanding the ‘how’ part of anything since in the college one is supposed to study the fundementals of the various subjects. I agree with Rod, that the combination of throery and practice is a powerful arsenal.

Thu, 16 Jun 2005 10:42:30, Phil Spitler, Could not agree more Micah, you hit the nail on the head on this one. I have been programming for over 8 years now and until recently never went to college for one day. The one class I signed up for I dropped because it was aweful. Style guidelines (e.g. hungarian notation) were of more importance than learning to write code. Needless to say, in the future I don’t see college playing a role in my programming career.

Thu, 16 Jun 2005 10:18:14, Rod Morehead, College can be a time of Mentoring When I went to Austin College, a small liberal arts college, I wasn’t sure what I wanted to be. But I took a wide range of courses, and discovered I had talent in Computer Science.

A computer science professor there, Mike Higgs, takes all his students under his wing, and gives them a firm grasp of the experiential and the theoretical. During college I served internships, putting what I had learned to work. After graduation, his connections helped me get jobs multiple times in my career.

The combination of theoretical and experiential is powerful, it allow ideas from both areas to cross-pollinate. I have know many software engineers who excel in only one area are the other, but the ones who have both are the most useful: they can combine the how and why.

Some people can teach themselves what they don’t receive during formal training, and college is not for everyone, but if you can I recommend it. Without college I would not have gained other non-computer science related skills that are invaluable in my day to day work. College helped me become a life long learner, which is a key ingredient in software craftsmanship, and gave me a mentor and friend.

Thu, 16 Jun 2005 07:46:24, Joe Kuhn, Add on comment about Micah’s Jack and Jill article There’s a critical component to riding a bike, the balance part, that you can teach your kid with a scooter before ‘graduating’ to a two wheeler. My kid was two when he got on the scooter I gladly bought him because I could see the opportunity. When he was three he was free wheeling all around the neighborhood on the littlest 2 wheeler we could find. It took him about 30 minutes to get the pedal coordination figured out when starting. I’ll always remember his older sister clapping and yelling, “you got it Johnny” when he did it all himself. Micah’s article is consistent with this concept of teaching the critical component to exclusion, if you know you want to be a programmer. College is over rated and over priced. So we can stop emphasizing the bs when hiring!

But some kids don’t know what they want to do when they go to college…