A few months back, I got a notice from Yahoo! that it’s was about to pull the plug on Briefcase, its free online storage service and that I needed to transfer all the files. There, I found a zip file of the very first industrial-strength project I developed almost 9 years ago together with some friends. When I got a copy of Visual Studio 6 from a friend, I decided to look into the codes again and what I discovered are traces of struggle, perseverance, and naiveness that shaped the coder that I am today. Every project is a battle. This is the first one and I had only the slightest idea of what I got myself into.
The project is a VB6 client-server application for an apparel company. It was used to compute wage for factory workers based on the work items (known as job) they’ve done for the week. It was originally a college project but the primary stakeholders, realizing the huge return of investment from automated process, tasked them to continue working on it for a price. Well, we didn’t really know the price at that point but the idea of making money out of the craft you’re trying to learn from school was just too enticing. I joined the team when it was realized that MS Access was no longer up to the job. In my case, my enthusiasm was further bolstered by the fact that I was still beginning to learn SQL Server.
The project became an eye-opener to the real nature of the craft I chose. I didn’t graduate with a computer degree but I decided to pursue programming thru self-thought because it’s the only way I can satisfy the “control freak” in me. I thought it would be fun, after all it’s about doing what you really love, right? Well, nothing could be further from the truth. It turned out to be a nightmare; capable of turning anyone into a zombie due to several sleepless nights and skipped meals. The same is the nature of software development as I experience nowadays but the big differences is that we were still naive then. We lacked the experience and knowledge about good software development practices. Exacerbating the situation were the comparatively primitive technologies we’re using which always compelled us to make compromises in order to achieve the best solutions. This post, and the ones hereafter, will explore the mistakes I made and how they influenced the subsequent projects I had. I will also discuss the by which they should be implemented using the most current technologies.
The Model and the Names
Virtually every business application deals with data so it just makes perfect sense if I start with the data model. I can say that I designed about 90% of the data model. Another member took care of the remaining 10% for an auxiliary applications which he solely developed. The first thing you would probably notice is the application of Hungarian Notation and underscores. I learned this style and the naming convention, which you will see momentarily, from the book I was reading at that time. As a beginner, you tend to be dogmatic and don’t even dare to ponder if what you’re imitating is actually right. I later found out that this style is not just hard to read but totally unnecessary.
There were more tables than what were actually needed. This is because I maintained history on some data which I thought would be valuable for auditing and report generation. This is actually a big mistake. Queries involving temporal data are not straightforward because you’re always dealing with composite unique keys involving dates. Besides, the stakeholder did not ask for it - I just assumed it. The adjustments we made just to cater for temporal data, significantly delayed the delivery of the project. I was guilty of that.
“As a beginner, you tend to be dogmatic and don’t even dare to ponder if what you’re imitating is actually right.”
The model included extraneous tables.
I did not use the IDE to create my database objects. Instead, I painstakingly wrote the script for the entire database! For a beginner, it’s a great way to learning SQL but it’s a bad practice simply because it takes so much time. Companies don’t hire you because you can write an entire script of a database. They hire those who can achieve things within the shortest period of time so that means being adept with tools.
Sample script for a table, complete with constraints.
“The adjustments we made just to cater for temporal data, significantly delayed the delivery of the project. I was guilty of that.”
Later in the development, I’ve had enough of Hungarian Notation and this couldn’t be more evident than the contact number column. From a book I referenced, contact numbers were stored as integer and I just blindly followed that. But having it so requires parsing and formatting in the UI. Worse, changing its data type also means making sure the procedure or views that used it were modified because the column name has changed. Coupling is the biggest headache from Hungarian Notation especially that time when there was still no refactoring tools. Another lesson I learned from this is that a column, even though they can be stored as numbers, should never be numeric unless it's being used in some kind of computation.
Some columns did not use Hungarian Notation anymore
What’s next
this point, it’s should be clear that I just scratched the surface of one laborious undertaking. In the next installment of this series, I’ll discuss the complexities involved in dealing with time-aware data.
No comments:
Post a Comment