Hello, CoRecursive newsletter subscriber!

It’s February now, and I have a new episode out here:

• ​https://corecursive.com/shipping-graphing-calculator/​

It’s the story of sneaking onto the Apple Campus to finish working on a project that got canceled. Each episode is only as good as the story, and it would be hard to find one as surprising and well-told as this one.

Mario Sangiorgio pointed me at Ron, and I’m glad I emailed him back in August ( and in September, October, and December - sometimes good guests are busy. )

Story Time

Ron’s refusal to let a project die made me think of my experience with canceled projects. There have been many, but one stands out because it was an unforced error. I joined a team working on an e-commerce project, but for some ministry of the Canadian government that had specific enough requirements, everything needed to be custom. We were excited by all the new-project things: Trying out that new library that might help. Deciding what the service boundaries were. And so on. I remember a lot of time spent working with queues. The team lead was very excited about queues.

I started going through all the requirements at some point, months in. The federal government can generate a lot of requirements. I listed requirements on a large whiteboard, and the whiteboard became something right out of a beautiful mind. Then I started pulling people in and asking for estimates. Things started adding up quickly.

It became clear that this project was way more significant than we thought it was and, in fact, way more expensive to build than we would be charging the client.

All the time we were working on the services and how to queue things, the project had never really had a chance.

And that was just the Dev time. Somebody wrote all the requirements I was working with. Someone had sold the client on this project. So many things had to happen along the way for no one to notice that the project was make-believe or, at the very least, not suitable for this company.

Greenfield projects – new projects – are exciting. But you don’t always learn as much as you might think because they often fail for big or small reasons before you get feedback on your decisions. For example, would our queuing system have made iterating on the backend easier? Would our XML-based web services approach have been a colossal mistake? Unfortunately, we don’t know because the code never went anywhere.

Youtube

At work, at Earthly, I’ve been creating some youtube videos. Our channel is here, and this video about Staff vs. Line, a topic I’ve talked about before, is my favorite so far. (See also related Twitter threads )

Thanks, Adam

​@adamgordonbell​