“Doing it Right” vs. “Getting it Done”

I am in the beginning phases of familiarising myself with an internal project at my company, and what I saw really shocked me. It certainly isn’t your typical “Student Project”; in fact, it would probably fail the more advanced courses.

In some sense, I feel quite disillusioned: surely what I have learnt (and in most cases, taught) in University would see some application in the real world. However, it seems that what I have learnt in uni is “How to do it Right“. In many real-world projects, including this one, the focus is on “Getting it Done“.

The project I am current assigned to is an excellent example.

The System

The System is a relatively featureful Time Tracking System. Employees log in, log the number of hours they worked on a specific project, and log out. Yet for something this simple, the System itself is broken is more than 1 way:

There is a list of “projects” on the left, which Employees can click to add a particular project to the current week’s timesheet. However, “projects” can also be sorted into “categories” and “clients”. Since the list control treats every single item as an item, Employees were able to add “categories” and “clients” as projects as well. While not exactly a critical issue, it is obvious that this is not the intended behaviour of the System.

Another problem was the “comments” mechanism that was built into the system. Aside from entering in the number of hours worked (into a textfield, no less), a small input area is overlayed next to it, allowing the Employee to enter in a small comment about that particular entry. However, the Javascript involved is strictly IE6 only. Meaning, it broke on all the other browsers that employees wanted to use.

Lets Be Realistic

This is not the first time I have experienced this “mentality” in my company. When estimating deadlines for a project, it is done with the intention of keeping cost low (cost being calculated as a rate by the hour). Thus, the mindset of the programmer is always to “get it done as soon as possible”. Is this what you’d call “Agile Programming”? Or is this just irresponsible coding?

Or perhaps it is simply impossible to “do it right” in the real world.

Share this post: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • StumbleUpon
  • Reddit
  • Facebook
  • Google Bookmarks

5 Responses to ““Doing it Right” vs. “Getting it Done””

  1. I guess it depends on the size of the organization that you’re dealing with, and also the kind of work that you do.

    A lot of the work that I’ve been doing over the past few weeks has been reviewed and made to be completely conformant, and optimal (without going to the extreme level).

  2. Bryan Grezeszak Says:

    Quality programming when done in an OOP manner saves time in the end, since you can just reuse classes. By doing this quality wins out in the end.

  3. @Bryan: I think any quality programming done in any manner saves time in the long run. It doesn’t necessarily *have* to be OOP.

    For example, C has libraries, which also promote reuse.

    However, in this case I’m not just talking about reusing classes and modules. That is a warped way of thinking that universities have instilled in their students. Proper encapsulation, abstraction, good structure will all save the day in the end.

    Unfortunately, as I was saying in my post, this thinking is very idealistic. More often than not (and more a reality these days), budget is a major factor. Even for a home-brewed project.

    How much time are you willing to spend? How much are you willing to let a deadline slide just so you can release a “polished” product? Remember, the time you spend could be time better spent elsewhere with a better financial result.

    And finally, too much planning for “quality programming” distracts the developer from what REALLY matters: what the software actually does.

    Of course, the point of my post was not to say “quality programming is BAD”. I was simply reflecting on the everyday choices I have to make, from a developer POV, and a business POV.

  4. in our environment, there is a set of ‘minimum expectations’. This is preset list of stuff that needs to be done in a project…it balances the need for getting it done and doing it right. everyone agrees to this set of (including the director) criteria. This minimum expectations help the team to know what is the very least that is expected from them. If they have time to do more, then by all means they can do it…just don’t do any less.

    Sounds like you need a similar meeting and list of minimum expectations.

    In terms of academia, the minimum expectation is what the professor is satisfied with. Probably will get a B or something. Anything less will get you lower marks…and more effort will get you higher marks (an A?).

  5. As you get more experience, you will do better work.

    As you do better work, you will get more trust.

    As you get more trust, you will get more time.

    As you get more time, hopefully, you will be able to focus on quality rather than quantity.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>