Do you ever felt disgusted by your Developing Techniques? like i do?

Just a few months ago, I went for a school's industrial attachment programme, which will allow students like me to work in a company for a period of time.

I was lucky enough to be sent to a manufacturing company where people there don't really know much about programming. I was assigned to develop an Excel VBA program that would analyise and plot overall production charts.

|*Wait a min, am i telling a story??, hmm... nvm|

During the development of the program, I was struggling on which kind of programming techniques shd i adopt.

Flexi-Coding (emphaize on Code-Reusing)
or
Hard-Coding (juz If-Else all the way, and copy and paste as much as you can)

I'm not a GREAT fan of the 2nd choice, so I take on the "long" development technique which usually need more time to think of the code structures to effectively be reused.

BUT... Unfortunately
|*Wait a min again, since you had read those on top, thank you, but pls bear with my english|

I am not able to meet my supervisor's dateline, which badly penalize my scores on "Reliability - Ability to meet dateline on assigned task". So in the end, it happened that i score lower than a schoolmate who uses almost a module of If-Else statements, and the program is not even more expandable than mine.

So guys, what will you do if you were me?

Shd i have taken advantage of my supervisor's lack of programming knowledge, and use the hard-coding technique? (and in the end feel really disgusted)

Shd i talk/argue with my supervisor's to give me more time? (which i will picked)


I really want to know how you guys handle this kind of situation, because I believe I will encounter this again in my future career.

pls teach me wht i shd have done?

Well, something like this happens often to me also. Your supervisor wants you to finish asap, but you know that the program will be like the always-giving-pain-in-the-programmers-heart monday morning stuff.
My solution would be having an arguement with your supervisor rather than accept a lower score. When you are persistent, at some time they will appreciate that. Just explain your reasoning.

Good luck!

I can understand what you mean High-Tag.

But sometimes reasoning out with your supervisor is not workable.
To manufacuring people time is money, they rather want a "buggy", hard-coded program which last about 2 years, than a expandable, reliable program which can last till the end of 32-bits age.

They also prefer to see visible improvement, than backbone improvement.

LOLz...

Remind me of my ex-boss, who thinks that
Adding a button to your GUI, is a greater achievement than creating a piece of data extraction codes.

Just fight for what you think it worth, if you think you can learn a lot using the right programming tech. then so be it.

I prefer to write thought-out and well organized code - ideally such that someone else can maintain it and modify it without having a seizure. I've had supervisors get on my case about how long it takes me to complete some projects. My one boss gave me the MS "Rapid Development" book as a subtle hint one time. At my current job I sometimes have the luxury of writing "good" code and taking my time within reason...however, we do occasionally have serious deadline crunches.

Now is one of those crunch times. I'm doing a high pressure team project involving two other parties (the demanding client and another vendor) and we have weekly demos and deadlines and volumes of code to write. Our code involves a lot of data from differing sources and lots of business rules that are in no way standard. A lot of our stuff depends on this other vendor's code and they usually break our stuff regularly with their changes causing us to write "repair" code and butcher what we have. Most of us are working weekends and many nights (but at least we can work from home during "overtime"). All of us are constantly whining about how much this project sucks and how we're writing the worst spaghetti code of our lives.

I guess my point is that sometimes you just have to make it work even though you'd prefer to "do it right." When serious money and clients are on the line you don't have much choice.

Paul

When you are writing code for someone else, and, more to the point, they are paying for it, they really have the last word. Even if that means writing non-elegant code. Managers rarely (and accountants never) understand that concept! :rolleyes: Keep in mind that the inevitable revisions may keep you employed later! :)