Software Development

It didn’t get better. For me.

I was really excited when I got this book. And that might be why I’m this disappointed.

After my mid-read checkin, I was hopeful because the project finally seemed to be moving along. Stickies on a Whiteboard was the next chapter and I loved it! Seeing them go through each tasks, canceling, and assigning them to a particular release was satisfying. I love it when the book is about Chandler. But since that chapter, I’m sad that the book has gone further away from the project.

It became a review of different schools of thought. Has software engineering stagnated or not? Does software development need a do-over? Could we hope to standardize the development process and improve productivity? It felt… theoretical rather than historical. A someone-said-this, but another-said-that. And I’ve had enough of the cathedral and the bazaar references.

There were some gems that I did appreciate though, like this quote from Joel Spolsky:

The real goal of a methodology is to sell books, not to actually solve anybody’s problem… The key problem with the methodologies is that, implemented by smart people, they work. Implemented by shlubs who will not do anything more than following instructions they are given, they won’t work.

Joel Spolsky

This and the Capability Maturity Model triggered my aversion to red tape. It made me vent to my partner how productivity metrics leads to players gaming the system and ultimately sabotaging productivity. The Joel Test sounded like something I could ask companies come job search time. “Masterpiece Engineering” where they monitored painters’ brushes per day and assigned Da Vinci to procurement gave me a chuckle.

I guess it can’t be helped that the progress of Chandler was slow for the time limitation of writing the book. Still, I feel that it should be possible to do a deeper look into the project instead of doing a review of literature.

My expectation might be clouding my judgment. Those in for a philosophical read on managing software projects may appreciate “Dreaming in Code” more.

How I found it

I found about Dreaming in Code by Scott Rosenberg in a Reddit comment while looking for software development books and I was stoked! I thought then that it was about the makings of a calendar app, and even if it failed, it excited me as a developer who’s also a serial planner. I mean, look at my sched!

The company I work for has a delightful book allowance, so I bought this book along with Structure and Interpretation of Computer Programs. I was very giddy waiting for it to arrive!

How Dreaming in Code was

I admit, it was not as I expected, and it had been a very frustrating read. I’m now more than halfway past the book, and page 173 (out of about 400) drove me to write about it.

Well first, it’s not a calendar app, it’s a personal information management system. Which is… GREAT! I’m not really looking to build a calendar, but more of something like a journal. So PIM! I actually drew some really rough mocks and requirements yesterday, and I acknowledge reading about Chandler gave me some drive to actually get started. I even named it Monica! Yes, I know, Chandler isn’t named from FRIENDS Chandler, but he’s who Chandler reminds me of, and Monica is the stickler type of person that would probably appreciate my app.

Now why was I frustrated?

As my partner noticed, I’m not one for set ups. I found the set up (initial chapters of the book) halting and jumping around too much. I wanted to get started on the app itself, not much on history! But looking back at those chapters, they were actually nice-to-have context. It’s like being ushered in to the software development world and meeting its culture. So this one’s on me.

I’m not going to pretend to know any better than these veteran software developers. I DON’T. I’m green, especially to software development. I don’t even have an IT-related degree! But I’m one with the author here. It’s at this exact page that I was despairing and thinking “WHEN ARE THEY EVER GOING TO GET STARTED?!”

It felt like a lot of meetings and going-arounds without deciding or committing to those decisions. But then I am reminded that even I face the same in the small features that I have ever worked on. A lot of planning and researching, trying out one approach, getting a dead end, trying another, gets another dead end, going back and forth between approaches, then realizing my first one was better all along. AAAAAAAAAAAAAAAAAAAAA. And that was just a small feature, not even as important as architectural decisions. These people were changing how we treat information. It’s ground-breaking. And maybe the foundation they were trying to build would prove its worth of the time they’re giving it?

How has it been since

I’ve just finished page 235, Chapter 8: Stickies on a Whiteboard. I’m happy to report that they’ve made much headway since page 173. They’ve finally had a demo day, thank goodness. They’ve shed a lot of features for a while to focus on delivering a working software. I think that’s a good decision.

By page 173, kudos to the author for picking that moment, it seems like they have overcome the project’s activation energy, so it’s been less frustrating for me personally (*laughs*). I’m finally getting insights on their decisions for the app. Chandler already looks like SOMETHING, and I’m getting inspiration! It’s also nice knowing the people who worked on it and their frustrations. My personal favorites are Andy Hertzfeld and Andi Vajda.

---

On another note, I’m happy this book drove me to write about it because this blog has been sitting on just one post up til now. Hehe.