Wayne Allen's Weblog

Big Call...

How long ago was the code written? Personally, I have discovered that code even I have written perhaps 3-4 years prior often seems crusty when I look at it again. Then again, SOME of my code does hold up, and as I see that, I try to jump onto whatever seems to have caused that code to continue to look OK even years later.

Also, I do concur that programmers who are good are often those who are driven to learn and grow. How many programming related books have they read in the last year? Do they have a development setup at home?

>How long ago was the code written?

I agree with your comments, but I am talking about freshly minted code, version 1.0 and all that good stuff. And still the code smells to high heavens.

I quit.

Not long before I handed in my resignation ( 3 more work days, and then I start the new job), I said to the new Architect/Manager and Buisness Manager. "Do you know what the difference between me and them is? Last night they were watching the new extended version of Lord of The Rings and I was writing code."

My old code sucks (most good programmers will agree that their old code sucks), but it can be fixed, by me or by you, without trouble.

There are a lot of people who write code because it is their job.

Programming is my craft.

It isn't about willingness, it is about hunger.

I experience these same things in our corporate environment. To change this I have started offering my services as a consulting-basis to other teams on an as needed basis. I offer to look over what they are doing or planning and offering my advice. Of course I can't force them to follow it but it does help.

Just recently I caught an application going into production that used web services to get all the data it needs. Reason being, just because they could. There was no business need behind it other than they thought it would allow the application span to grow easier. Considering our target audience will be .NET developers there was no need for this. So I suggested they build the business services API for the data access and if in the future we need this data exposed to non.NET platforms or external vendors we can use the API objects to create the web services ... they decided that would be the better way to go. (I only got wind of this because our NT admin team was haivng trouble configuring the web services to work in our environment and I'm the go to guy for all .NET issues in the end)

Just one simple example of success.

Now one of a failure.

We are implementing MSMQ messaging to transport MAINFRAME data to our RDBMs (informix among many) well the MAINFRAME guy that understands a little bit of Win32 environment started setting up MSMQ and wrote the entire communication API without my input ... they didn't do to bad but its still not good .. they won't take any advice on how to code the protocol handling ...its very limited currently and I'm just glad I don't have to use it ... well to get messages around they were planning on using triggering in MSMQ to run instances of programs to process queues ... this is ok but there are some huge downfalls considering we will have thousands of queues with thousands of programs processing them ... the maintanence is going to be huge ...

I suggested windows services - 50 lines of code to get one up and running (and installed) ... but they can't see the benefit or are afraid to take the unknown route. I told them that would be better (at the time never having written the code, 30 minutes later I had simple proof of concept) ... they still seem to be pushing me off

And the only reason I ever got wind of this? Because they were having security issues and no one really understood the architecture of the infrastructure for the messaging api's ...

In my honest opinion our developers are shooting themselves by having too much pride and not coming to someone who is more knowledgable in areas of architecture (especially in correlation to .NET) than they are... I'm not saying I'm a master, but I am at this company ... things are better

I convinced them to use VSS and start a weekly training meeting that is optional for learning new techniques and tricks ... addressing issuess ... it has worked pretty good ... except for where they would follow an article in gartner rather than take real-life advice from people who have had experience in this new world (to them).

Ok enough rant, that's just me but I'm sure the same scenario is out there ... :) So sadly I can't change jobs and expect to outrun this environment ... there are those who are just there 8-5 and not a second more because it is their job ... on the weekends they spend going out with friends i'm at home reading new articles trying out ideas ... learning ... not because i'm better than them in all things but i have the drive to progress ... the feeling of not yet reaching my maximum potential ...

Yes I get this all the time.
My current role is pretty much making sure the development teams do things that make sense.

We also do code inspections. This is not ideal as it's usually too late in the process to have them change their code.

Basically I think it comes down to someone's attitute to learning. If they are not interested in learning, then they won't be good programmers!!

<disclaimer>
I don't know ANYONE posting comments in this section (to my knowledge, anyone can be anyone else on the internet) So I don't know if you can back up your claims of greatness or not.
</disclaimer>

But you always have to be careful if you think you are a big dog because there is always a bigger dog.

I've been coding for around 10 years, playing with computers since acoustic modems were new, probably just a pup compared to some people posting comments here. I've dealt with a lot of prima donna coders, some I was more skilled than, some less.

Most coders will always think that they are a better coder than someone else, or that they KNEW the correct way to write an object or method or function. Sometimes there is a better way to do it, sometimes it's just different. Every good programmer I know always thinks they can tweak a little more performance or make a block of code more elegant.

I've written code I'm not proud of and that I think I could architect better, hell I'm writing some at my job now. But it's getting the job done and my deadline is "yesterday".

You may think the code stinks to high heaven, but it may get the job done. And whether or not you are coding for fun or for a paycheck, at the end of the job you have to SHIP.

SHIP !!
That's just the sort of attitude that is at the root of the problem.

What a terrible reply !

There is always a bigger dog, and the code can always be better.
I'm going somewhere where I wont be the big dog, just one of the medium dogs. This is good, because I realy am a medium dog (with the potential to grow).

I know more today than I did at the start of the day yesterday.

I didn't know the best way to do it, but when you look at what I did, you will say "he did this because he wasn't aware of the ABC123 pattern".

Shiping the product is not really the end of the project, you also have to fix the bugs when they come in.

>But you always have to be careful if you think you are a big dog because there is always a bigger dog.

I don't think I claimed to be a "big dog", but I will claim that I have lots of experience and can tell the difference between good and bad code.

> I've written code I'm not proud of and that I think I could architect better...

Agreed, but why do we do that to ourselves? Someone will have to fix/change it eventually. We coders give ourselves bad reputations when we let management bully us into more and more features with less and less time. Coding crap just to get it done is not the right solution in my view.

xyz,

You are absolutely right - "SHIP!" is a terrible attitude. The problem is that it's the attitude of many managers. How many programmers are eager to cut corners and release stuff before it's done? Not many, I'd bet - they are the ones who'll have to deal with all the bug reports, after all.

In my experience, programmers cut corners and write sloppy code because they are struggling to meet unreasonable deadlines set by incompetent managers. It's a sad fact of life, but you aren't going to get anywhere by blaming the programmers in this situation.

Bad code is due to a couple of reasons...

1) There are sloppy and lazy programmers out there who are just bored or otherwise uninterested in there jobs. Why can some mechanics fix that noise when others can't?

2) MANAGERS and unreasonable DEADLINES. I dont know about any of you but I am never done with a project. I am picking through code up untill the very end, and even then it is never done to my liking!

Most people write bad code for several reasons -- be it a bad design, insufficient knowledge, boredom, or plain simple stupidity. However, from what I have seen, programmers who think through the problem before writing even a single line of code, code better on an average. Also, programmers who can think of programming without associating it with a language do write better code. These are the folks that think in terms of algorithms before thinking in terms of code.

Most of the worst code I have seen has been by the programmers who were trying to be the most clever. Usually it's those guys who write code that is complex... to show off how smart they are. In fact it is the opposite. The more complex the code, the dumber the programmer.

Just the other day, I saw a class that had manager type duties. Something that was in charge of a whole bunch of functionality. Well, it had a member, a hash map I think that kept some stuff. And guess what that hash map kept? That idiotic hash map kept instances of it the manager class!! Yep, it kept all these pointers to the manager class that was kept on the heap!!  It was a piece of shit, that really should be torn out and redone from scratch. Like I said this stupid code was written by a guy who was really too clever for his own good.

Oh, and the comment about how the product has to ship? Good call!! NOT!! Unfortunately it is always the business managers who determine when the product ships, and not the programmers... or QA. So even though a critical mass of bugs are still in it, management doesn't care. Just fix the critical ones, and leave 90% of the rest in there. Makes me want to quit and start my own company.

Honestly, here goes.  People skip the basics.  Do they learn programming logic first?  If not do they go back and pick up a book on generic logic?  I know many programmers that have years of skill sets and projects completed, that all say...I would have done that so different, or been faster, made less mistakes if only I learned or read this years ago.  Also the advent of the script kiddy.  "This looks good, so lets copy and paste"  It was not honestly good, you just did not know any better.

Programmers and coders also need to start looking at the bigger picture more often.  Security is not a check box.  It is an ever changing way of life and there is no one way destination.  Many programmers have the I built it, it worked, I am done attitude.  It worked on your PC or your small controlled environment, now what about a large network or world wibe web?  Lets define what "it worked" actualy means.  You made a form.  It passed data on.  Is that data safe?  Is it reliable? Is it a copy paste one size fits all, and you just changed the text?  Are you reading about exploits and understanding how many months of your work may need a simple adjustment to stay viable to your work environment.

Bad code will happen.  Bad programmers keep using it.  Good code is the result of always researching, learning, and adjusting.  There are no finished projects, unless they are retired from service.