Comments on Valued Lessons: Garlic Programmers for Silver Code?

Big Ball of Mud (1999): "It is interesting to ask...

2010-06-04T22:47:55.376-07:00

Big Ball of Mud (1999):

"It is interesting to ask whether some of the differences in productivity seen between hyper-productive organizations and typical shops are due not to differences in talent, but differences in terrain. Mud is hard to march through."

Thanks, Dan. I updated the link.

2010-03-06T11:34:44.822-08:00

Thanks, Dan. I updated the link.

The "permalink" to the silver programmers article ...

2010-03-05T12:16:19.211-08:00

The "permalink" to the silver programmers article is broken, but this link seems good: http://www.knowing.net/index.php/2008/01/14/no-silver-programmers/

You may be missing (or misunderstanding) the cause...

2008-02-08T03:37:00.000-08:00

You may be missing (or misunderstanding) the cause/effect relationship between your "good code"/"bad code" examples and the "results side" (you may not be - it's always possible I'm just not paying enough attention to what you've written!)

Basically, it's not a case (for example) that if you write "good code" it'll be easier to change: rather if you make your code easier to change, then it'll be good code.

So:

* If you write less code to achieve the same result, it'll be good code.

* If you write code that's easy to understand, it'll be good code.

* If you write code that's safe to change (I'm thinking unit tests, good naming conventions so the next guy knows EXACTLY what you're using that variable to store, etc.), then it'll be good code.

* If you avoid duplicating your efforts (i.e. if you spot that you're doing it the first time you see it and change your code to avoid doing it in future), then you'll write good code.

* If you write code with the change-compile-test cycle in mind (build scripts, continuous integration tools, automated unit tests), then you'll produce good code.

* If you use tested reliable libraries for the common stuff and focus only on those factors unique to your problem, then you'll produce good code.

The exception is that last one - the good code does cause the "fun" (and the bad code causes the stress).

one mans treasure is another mans trash.I'm sure t...

2008-02-05T14:00:00.000-08:00

one mans treasure is another mans trash.

I'm sure the people who wrote your 'bad code' thought it was great and easy to work with at one time.

I couldn't agree more. It might take a bit more ti...

2008-02-05T07:12:00.000-08:00

I couldn't agree more. It might take a bit more time initially to set yourself up, but you will definitely reap the rewards in spades later. Instead of fighting with your code base, you could be working with it.

For my company LandlordMax, when I initially started it, I took more time initially to develop the underlying architecture, frameworks, etc. And what a difference it's made. If this hadn't been the case, there's no way we could have added so much new functionality in the amount of time we did!

As well, there's a term called Developer Debt, or Technical Debt, which basically means that over time you will dramatically increase your cost to do anything if you don't do it right. It can quickly compound out of control.

If you're interested you can read about it here.

I can clearly recall the same situation occurring ...

2008-01-23T06:05:00.000-08:00

I can clearly recall the same situation occurring in my own professional career, within the past year sadly (i've since moved back into the world of my home office as an independent software engineer.)

I was called in to work for a hosting provider to revamp many of their backend processes and interfaces, plus some automation and what not. The environment was in perl, so I know instantly that there would be some hellish times ahead. Anytime a code base exists in perl that isn't a series of small targeted scripts, there is generally spaghetti code and ugliness abound.

I won't go into the specifics because I've already written that elsewhere on my own technical journal over a series of entries and months (http://www.codedevl.com) but a quick synopsis (and reason for leaving the job) was as such: I found my productivity reduced to a fraction of what it was prior to that position, and since leaving I have returned to my normal pace (a considerably high factor. What would take 5 days in that position takes about a day now, and I'm far more confident about the build quality of the current code.

That situation partially revolved around the fact that the codebase was written by two people. One was a C code who got into perl but never stopped using C idioms, hence instead of using libraries and packages (.pm files), he named them with .h extensions and included them with the include directive. Global variables abound, no my, no use strict pragma (which is a must for well designed perl), and secondly the replacement programmer was the owner. He was not a coder by trade and it shows in his work. Yes, the system worked, but only with constant management and considerable human interactivity on a routine basis, including direct database manipulation of items which should have been controlled through coded mechanisms, especially the financial pieces.

The level of depression I felt due to the disappointment by myself at the environment in which I was trying to operate made me realise that this problem was due to 10 years of a base codebase, and individuals that never took the necessary time to learn real best-practices, implement systems for peer review, setup versioning repositories (none had existed prior to me), and never learned that you shouldn't work on live systems as you're just asking for trouble.

Either way, I do agree with what has been presented, I only wish I didn't have personal experience in that kind of environment, because it drained the life from me, and took away several months of productivity, which could have been spent engineering beautiful code and systems.

eric

Oops. Thanks. I fixed it.

2008-01-21T22:13:00.000-08:00

Oops. Thanks. I fixed it.

" Good code leads to less code, and less code is s...

2008-01-21T16:51:00.000-08:00

" Good code leads to less code, and less code is slower to work with" ???

So true!!!

2008-01-21T16:11:00.000-08:00

So true!!!