Dreaming in Code is a book I have been reading by Scott Rosenberg. It is a fascinating look into why software projects so often flounder and fail. It would take a pretty thought-stimulating book to pull me back into the blogosphere again, and this book is it. This one has me excited folks.
As a computer science and mathematics double major, I feel like I have my fingers on where the computer science field is headed. Programming is becoming increasingly mathematical and elegant. Gone are the days when we banded together into small groups of two or three people and spent a night in our parent’s basement coding in Basic to create the next big 8-bit killer app or the days when assembly showed us a repetitious and slow picture of programming. Now software of all kinds is put together by professional teams of programmers relying on highly complex and optimized software. If you are a programmer out there and reading this, it is all sounding very familiar, I know.
What amazes me is the lack of planning and forethought that Rosenberg seems to imply goes into designing software. He leaves his readers with a feeling that programmers are mavericks of some sort – fly-by-nighters who get the job done and then run to the next task without regard for documenting what they have done. To a large extent, my guess is that this is partially out of a need to entertain his readers that Rosenberg does this – but I can’t help but feel like there is a certain thread of truth behind it. I have seen more than my fair share of overdue projects thanks to ill planning and preparation.
This is a disappointing revelation. I have learned first-hand at the college level, what poor planning and management can do to a software project. When I am writing code, particularly with a partner, I spend the first several hours in front of a blackboard, not a computer. Also, when I run into troubles programming in the middle of a project, I take time to step back and hit the chalkboard again. I talk through my ideas and work hard to make sure everyone knows my view. I’m not hesitant to throw out prior work and start fresh.
This leads me to the type of team dynamic I see quality software thriving under. There must be one leader of the team, someone not afraid to make a decision without as much information as the team might want to have… someone who will keep the project moving forward and not backward. That leader, however, must also recognize and yield to tension from his team. If a member has a different idea, a different structural approach, it is the job of the team leader to ensure that view is heard. Often if I am playing the leadership role, I will hand the chalk over to the person who wishes to comment on my scheme. “Don’t just tell me your idea, draw it out so we all can see it, it’s probably better than mine” I tell them. Ninety percent of the time, that is the case… my partner or teammate sees an easier way to tackle the problem we are working at. That is part of the process of software design though… teamwork is vital.
That is not to downplay the importance of individual contribution. I approach programming like I approach mathematics. In math, when you are stumped by a hard problem, you mull over it a while… you let it seep into your subconscious until everything you do reminds you of different aspects of that problem. It has been said by some that mathematicians have a haunted or aloof air about them; that is because they are always so focused on the abstract… on the cleanest solution attainable. It is the same definition of elegance that software designers strive for in their code that mathematicians strive for in their proofs. Master one, and you will have a good idea what it takes to master the other. While I can claim to be no Einstein at either mathematics or computer science, I have written my fair share of proofs for classes and have a good mathematical intuition for an elegant solution. It heightens the senses and makes you feel alive. It is better than any drug, it must be. The adrenaline kicks in and the endorphins fly. There have been times both in programming and in doing mathematics where I have been so impassioned by it so as to be driven to let out a sort of primal scream – an audible reaffirmation of my success, either at comprehending the beauty, or contributing to it.
Non-“mathies” or those foreign to programming will likely have little idea what I am talking about here… at least with regards to mathematics or computer science. For those of you who fall into this category – think of something you excel at (something in the arts works best for this thought experiment, but any asset will do). Think of the feeling of elation you get when you successfully complete a task related to that asset of yours. That feeling, that fleeting second when you could be no more proud – that is a programmer’s nirvana. It is that feeling software endeavors must capture in its members. Programmers’ individual contributions to a project should elicit that sort of “nirvinic” reaction from peers.
I am convinced that with the atmosphere of teamwork and programming nirvana I have spoken of, that fewer software projects would fail. With a good problem specification and these traits, any software team can and will develop something innovative, useful, and elegant.