Feb 20, 2020
Kapsul3D : A 20 years old pet project post mortem
20 years ago, I was a junior programmer developing device drivers and I was enjoying Unreal Tournament with my fellow co workers.
This is a short post mortem on a very old personal project. What I learned and what I wish some mentor would tell me.
I was a total noob in software development but I believed I could do anything with my poor knowledge. So, why not building a 3D modeler from scratch?
My math knowledge was also miserable. But I still think with just a couple of operations (say dot product, cross product and vector transformation) you can already achieve a lot.
I’ve spent countless hours doing, reworking, deleting portion of code. I didn’t know what I wanted. If I saw a feature from any authoring tool that looked cool, then I had to replicate it. Even if it’s bigger than something I could chew, no matter what, I had to try. I didn’t even think about how useful it should be or why I should make it in the first place.
This leads nowhere and is the first lesson: Do it small, make it tiny but make it useful.
Of course, with many half finished features. Mostly untested and just stable enough to make a screenshot, this ‘software’ was a collection of unfinished work with duct tape.
Lesson 2: one finished feature is often better 100 unfinished ones.
‘Often’ and not ‘always’ ? Well, it depends on the scope of your project. If your pet project is meant to learn/introduce yourself to a particular subject, you can stop when you understand it. No need to make it production proof.
I introduced myself to a lot of algorithms. Some that I still use today. It helped me choose more wisely between different tools and implementation later in my career.
Lesson 2B: 100 unfinished tests are sometimes better than 1 production proof features.
The code is crap but the toolchain is maybe even worse. I still feel guilty because I didn’t spend time thinking how I should do things. I used VisualStudio 6 at the time and the concepts of dependency, build system, and auto-tests were totally unknown.
Ho! man! How tedious it was to build binaries. Right click on every project to build it. Any plugin that was not in sync with a change in a header and I would crash.
Lesson 3: If your project is more than 1 library/executable, find a way to automate build and tests.
Needless to say I didn’t know about test units. Broken things kept being broken for a very long time. No auto-tests either. This didn’t help me in keeping motivation. The more code I threw in, the more broken it was.
I had mixed feelings about users and releases. I was split between doing what I want without caring about users and getting users to improve the software and keep motivation. As I didn’t choose, I got worst from both sides.
Lesson 4: Know when to stop your pet project or plan and support releases for your users.
From those times, I mostly missed one thing: I was reckless. I could start something from scratch believing it would end up being something amazing (and failing along the way). Now, I’m better at preparing, doing research and planning. I see the difficulties in a project much earlier now.
Moreover, there were fewer 3D enthusiasts and way less documentation. Nowadays, there is a good chance that someone already did something like your brand new shiny idea you had last night. Less discovery but more on the long run software development.
I didn’t use any SCM software at the time and often lost code source but I’ve been lucky enough to keep a copy.
See the mess here : https://github.com/CedricGuillemet/Kapsul3D
At the time:
- ICQ was the IM you used to chat
- I did one version with C++ builder 1.0
- I was pretty experienced with MFC 4.0 after some months.
- Visual Studio 6 was my IDE of choice
- Only 30 hours a month with a 56Kbps modem for accessing Internet
- Winamp and 10Gb+ of MP3 was the best way to enjoy music while coding
- I miss flipcode.com
There is so much more to say about this project but I want to keep this post short. More next time!
