Search This Blog

Loading...

Friday, November 20, 2009

The Mistakes I Made in My Programming Career

You don't usually see people ( including me!) talk about their mistakes openly. But I think it is good to think about the mistakes we made in the past, so that we don't commit the same errors in the future.

I've been a professional programmer for about 5 years now. Like anyone else, I made mistakes along my way. Usually I didn't recognize the wrong thing I did right away; I only knew about the mistakes after being exposed to the correct ways of doing things. Hopefully after reading this post you would draw something useful from it and won't make the mistakes ( and pay the same price) as I did.
  1. Not using a proper ORM

    Data Access Layer code is always messy, tedious and boring. I remembered when I was first doing a simple internal bookkeeping application, I was horrified at the amount of code I had to write just to get the basic plumbing done. So I started to plug away the ADO.NET and manually coded up a home-brewed-with-a-very-specially-customized-to-specific-table-schema ORM to serve my purpose.



    A few months later there were some changes in the business requirements, and that cascaded into changes in table schemas, which led to a modification of my ORM, which was so painful that I discarded it all together and opted for strongly typed dataset adapter



    For a while this thing actually worked. But still, I wished that I used a proper ORM ( such as NHibernate) for the job. At least I don't have to worry about changing database vendor when my users grow in numbers.




  2. Not learning generics soon enough.



    I started my career as a programmer in .Net 1.1 days. The problem with .Net 1.1 is that it doesn't have generics support. As a result we couldn't have strongly typed list and could only be satisfied with the bland ArrayList. But using Arraylist, with casting and boxing all over your code is just painful to read and write. So we used CodeSmith to generate strongly typed collection list. But as the codebase grew those custom generated lists were becoming a monster on their own. Because I can modify the code easily, I often step in and change a method's behavior to suit my purpose, and that caused confusions and bugs later on.



    I should have switched to .Net 2.0 and started to use generics as soon as it is available, instead of creating more and more custom collection lists that are simply unmaintainable.




  3. Reinvent the wheel



    New programmers always like to reinvent the wheel: "The current implementation wasn't good enough for me so I have to rewrite the whole thing from the scratch". I once thought about writing my own UI controls because Windows Forms UI controls were just too unsophisticated for my use.



    As we all know there are a lot of excellent .Net UI control tools available; my GUI tools were not as good as those commercial ones, of course. I was just too naive then.




  4. Too much documentation.



    Code documentation is good, because it explains, in plain English, what your code is doing, right?

    Wrong.



    Documentation is often staled, outdated or downright wrong. I spent a lot of my time documenting my code ( XML documentation, remember?), only to find that I needed to update the documentation when I changed my code. Updating the code is a must, but updating the XML documentation isn't; it's a liability, it sucks time, and it serves no purpose. Eventually I ran out of patient changing the XML documentation and moved on to something else.




  5. No automated build



    Application deployment and packaging are comparatively easier than programming, and so I put a very low priority on that. Soon, I was receiving complains from everyone the build wasn't working. "Prerequisites are missing, how to fix it?";"dlls are not updated, can you please send me a patch?";"Why the icons are running away?" and calls alike were reaching desk like avalanche.



    At the end of the day I was worn out, not because of programming, but because of mind-numbing re-deployment and repackaging process. I could really "save" sometime from writing the automation scripts, but the time I wasted on fixing every errors and on supporting other people was many times more than what I could "save". Your software should be built at one click, more than that is a waste.




  6. Rely on visual inspection and debugging too much


    It's so easy to come up a form and display your output. And Visual Studio is so powerful that one can easily step into the code and inspect the value on the fly. But debugger is harmful if you indulge into it too much. Imagine if your method will only get called after the application is up and running for 45 minutes, are you going to wait 45 minutes to reach that point and then only start debugging?



    A better way is to break the application into sub-module that can be called independently. In this way you can just prepare the input that produces the faulty output and test it from there onwards.




  7. No unit test



    I used to think that my application is trivial, that it can be easily covered by manual testing. Unit testing is for something big, and sophisticated and not for me. The outcome of this was the application grew into a monster, with no separation of concern, hard-to-refactor and completely unmaintainable code base. There was a point when I was afraid to make even the slightest modification to my code because any changes may or may no result in breaking changes. There were a few times when a mysterious problem suddenly surfaced out of nowhere, and the root cause was a breaking change I introduced a few months ago. Working with this kind of legacy code is not just boring and straining, but mentally stressing as well.




    But with unit tests, life improves dramatically. I wish I could have learn the art of unit testing, and practicing unit testing starting from day one. It's a shame that the school doesn't teach unit testing.




13 comments:

Tom Richards said...

Very good summary of my "mistakes" also. I think that there just wasn't a really large community of developers that wanted to learn. No excuse any more - the communities are there (this blog for example) and the tools make the "right thing" easier.
Thanks for the reminders.

Anonymous said...

I'm not sure I feel the same about unit tests. At my company we have extensive unit tests and over the 10+ years I've been there have found that they tend to waste more time than anything. If you compare the time saved by a unit test catching a regression (next to nil) and the time spent creating, updating and refactoring a unit test because we improved a feature, We spend a great deal more time fixing broken builds and updating unit tests. A big waste of time!!

Anonymous said...

It is extremely interesting for me to read this blog. Thanks for it. I like such topics and anything that is connected to them. I definitely want to read a bit more soon.

Rick said...

Thanks for the nice post. I think you've got some really good observations there-- please keep on blogging...

RIck

İlkin Ulaş BALKANAY said...

Many developers do not see how unit tests save lives. I can not imagine working on a software project without automated tests and continuous integration. It must be like diving at night without a flashlight.
Thanks for this nice post.

Amr ElGarhy said...

Nice list, very good summary of most developers mistakes, thanks for sharing.

kerseyscott said...

Speaking of unit tests... For years, I have refused to take a project (or job) without previewing the database design first. I suspect that in the future, I will feel the same way about unit tests.

kerseyscott said...

Speaking of unit tests... For years, I have refused to take a project (or job) without previewing the database design first. I suspect that in the future, I will feel the same way about unit tests.

jrs said...

I disagree on the comments- they are very important for telling other developers (or yourself, 3 months later) why you made certain design/coding decisions, and what is going on with a particular class.

the documentation I am talking about is mostly in-line documentation, which is *right next* to the code, so if the code changes; then it's obvious what needs to be changed.

yes, it's more work; but then it will save you hours or days worth of work down the road, it's a good investment of time.

Anonymous said...

Dude, fix your links to external pages.

jammus said...

I don't think it's fair on yourself to label these as mistakes. No developer begins their career with in-depth knowledge of every tool/best-practice available to them.

Interestingly enough though they resonate with me as I approach my sixth year of professional development experience. Makes me feel like I'm growing up. Cheers.

Anonymous said...

How about learning something other than .NET?

I think not getting out of the .NET space and over into a dynamic, open source language like Python or Ruby was one of my big mistakes.

I learned so much more about development by branching out beyond what MS puts out.

It isn't easy, but it is rewarding and it pushes your skills to a whole new level.

Seymour Cakes said...

I think sticking to only .NET will be a bigger mistake in the long run. :-)