Problem: My parents used to organize their grocery shopping as follows. My mom wrote down what was needed on a piece of paper. Then in the evening my dad called before leaving from work and asked for the list to be dictated to him over the phone. So my mom did that. An hour or so later, when my dad was already in the store, my mom called him to add some more things.
Being a passionated software developer with no current project at hand, I decied to try to optimize this procedure a bit. So I made a simple database design involving obvious tables such as "shopping lists", "items" and "users". But what if a household wanted to have one shopping list with two or more users? Ok, so I split the "users" table up into an "account" and a "user" table. Then, really asking for complexity, I thought I would add some permission relations on top of that. And an account log. Three more tables after that, I - again - thought: what if there are shopping lists that are very similar, how could we help the users by allowing them to reuse previous shopping lists? Well, we could introduce a concept of what I called "list stereotypes" (a more proper name would be "list templates"). Ok, two more tables...
...but, how do we make money? Ok, either we expect/require the users to pay for the service (ehm, bad idea), or we use the data they input to maintain individualized marketing schemes; i.e. let advertisers target the users that are most likely to buy a product when in the store. For example, if a user has milk on her list, then maybe the collected data says users with milk on their list are likely to buy youghurt too, and thus showing a "would you like to buy yoghurt" hint to the user while in the store would often be interpreted as help rather than advertising - a win-win solution. So to support that, I added a marketing table group in the database.
With the database design essentially completed I moved on to the next problem - the problem of mapping relational data to a class model. I found some very interesting reading in one of my books on the topic: Patterns of Enterprise Application Architecture by Martin Fowler. I reviewed two common patterns used when encapsulating database access: Active Record and Data Mappper. Active Record has the underlying requirement that the class model has to more or less correspond to the database tables (i.e. an isomorphic schema), which would leave me with no freedom to form the class model in a natural way. So I discarded Active Record in favor of the Data Mapper pattern. But while the Data Mapper pattern is great when you look at what it accomplishes, it's not so great when you realize its complexity and at the same time feel the urge to implement it. This was the case here.
So I basically started to design my own Object-Relational Mapper (ORM) framework. I read and learned a lot about related patterns such as Unit of Work, Identity Map and Lazy Loading. I worked iteratively between framework design (UML) and its implementation. I attempted many different approaches and filtered out those that suited me the best. I was so into doing the ORM layer that I stopped the development of what motivated its existence - the shopping list app.
With time I started to focus more on my studies than this project, and what finally killed it (the project) was the fact that I got hired by Dimest AB. Looking back, I don't regret changing focus from the Shopping List app itself to the ORM that was meant to support it. Of course, if I was doing a project for someone else, I would not have allowed myself to do things like that. But this was my own project, and I learned a lot of valuable things that were of much use when working for Dimest AB.
Please note that I did not write so much interesting code on this project. The written code is more of an exploration of an experimental ORM interface. To see PHP code that actually does something, please see my template engine project.
An unedited work log is available here covering this and two other projects. A total of about 500 hours were spent developing the shopping list project.
Please note that the documented work is the effective work; i.e. no lunch, unrelated browsing or other significant breaks were included but strictly the time spent on focused and productive work (I used a physical timer which I stopped as soon as I went away for a break or started to do something unrelated). In addition to that, I was hard on myself and did not include so-called "unproductive days"; these simply appear as having zero worked hours. However, far from all days with a zero working time were "unproductive"; some were simply spent on studying, building projects or even vacation.