Your argument that it's easy is contingent upon it being a simple abstraction.

A complex date formatting situation may involve multiple, incompatible calls to check locale that you may determine do the same thing, but are not sure, calls to check business/holiday calendars that again, should return the same, but are not entirely sure. And these different calls may occur in different subsystems that do not currently share any module that you have access to. And the only way to write code that both subsystems have access to is to change a network server they both connect to and it's written in a language you don't know that hasn't been rebuilt in years that you're not even entirely sure the source code you're editing or the compiler you're using are the same that were used to build the current executable.

When you hear big financial companies legacy system, you almost automatically assume a ridiculous situation like above.

Edit: even worse, there may be another system, controlled by another department that somehow reads output that would be altered by your change and parses it, which may end up breaking due to your changes.

I'm mostly arguing that you should never be done just because something works. Sure you can start with that and treat it as a prototype but I just can't fathom a mindset where you don't just improve the code right away if you know it's not ideal.

I mean do you also skip the tests because after all all you need is running code, right? You can ask the draw the line question in either direction.

And my claim is that it's a lot less "dangerous" to think like I do than to think like the people in your examples. I'm also not claiing perfection by any means. I'm certainly not a great programmer by any stretch of the imagination and I'm sure I have written code where others would just go "WTF is this real?" but the point is even a bad programmer should always strive to improve the code as much as he can (for the next guy up).

I'm also not talking about optimizing at all I'm talking about writing code that is sound from an architectural POV (i.e. not complex mostly.)

Also, and this is a different debate but I'll mention it because it matters, you seem to be used to a very different style of management than the one I am used to. Your examples don't even make (much) sense to me. If you have to finish some system before the school year/season or something else starts you shedule enough time for that including the time to make sure the code is well written. If you can't make sure that's the case you don't take the contract.
Programmers are very, very, very valuable and it is extremly, extremly, extremly important to gurantee that they are almost never under time pressure. Taking too many contracts, rushing stuff and thinking way too short term is by far the biggest problem I have seen in failed (or miserably running) software companies.

Sure sometimes **** happens but it certainly should not be the norm. A scenario where a programmer is routinely forced to basically commit the first working piece of code is what I'd call management failure.

You don't get out of the classroom much do you?

I think at least two people have made quips pointing out some of your silly assumptions.

You just replied to me.

I have seen this a couple of times and it must be because I mentioned that I work in academics now.

I have worked both as a programmer and manager at a software company before and it was basically run on the principles I outlined.
Non-trivial software, too. An ERP system with pretty strong security concerns.

The one thing I will say though is that I would not take a job (any job, not just programming) at a company that treats programmers as replaceable cattle. I just strongly belive that treating programmers as valuable and taking pride in code quality is the right path. Sure companies can run on other principles and can successfully run on other principles but I wouldn't want to work for them and if I ever start a company I certainly wouldn't run it that way.

I can't fathom not fathoming this. I mean I laid out the reasons why I'd leave it not ideal.

Sometimes I do. It's rare but yes I have written and will continue to write untested code. My whole point is that as a developer you need to constantly be evaluating if the work you're doing is 'worth it'.

I've done very little contract work. The last couple of years I've been with a start up and our deadlines are things like "If we don't have progress to show by this point in time we run out of money and won't get any investment money", or "We have a great launch opportunity at conference X we need to be ready for public release so that we can make that date".



Edit: I realize I'm doing a bad job of this but in the interest of trying not to be snarky - I don't disagree that thinking way too short term is a major problem at a lot of software companies. But that doesn't mean the solution is to think only in the extremely long term.

Aside from shoe's comments - Tech Debt is actually very well named and quite analogous to real debt. There's definitely a cost for carrying it - but it does let you experience short term savings for a long term cost. There are lots of cases where that's advantageous for the business.

And as software developers if we don't realize this and stick with this bull headed insistence that we need to be coddled and given a chance to write perfect code that will last generations we're going to be ignored by management because its not a practical real world solution. Instead we need to acknowledge that sometimes we need to make short term decisions and lay out the costs and implications of that decision. Then we gain credibility and can actually build a really great software company.


Yeah... this has nothing to do with what I'm talking about.

I'm more than willing to drop this entire debate. I'm an ivory tower academic now so it's not like I care anymore.
I'm also sure the majority of companies don't work the way I prefer. Maybe I just got really lucky to land at a good place. I'll even concede that I'm completely wrong if that's what it takes.
[I'll bump it if I ever start a company that runs on these principles though..well only bump if it's profitable to gloat LDO]

Let's talk about fun stuff again

You can have pride in code quality and treat developers well while still acknowledging that there are times to take on tech debt.

I have a feeling we agree 95% anyways and argue about the 5% difference.

He didn't mention any of this stuff. All he said was to introduce a function that does the date formatting because that was determined to be the solution in this case. That's it, nothing less nothing more.

It's really super simple to digest. If everything you mentioned had to happen then the person who decided that all you had to do was a wrap a stdlib's date function was wrong (aka., the person who thought of this hypothetical situation + solution).

The way I implemented it also wasn't the point of writing it. It was just to show that they do the same thing. How the function was named or used wasn't even relevant. I didn't even think about that when I made it, I just named it "niceDate" because according to the spec it made the date nice.

Any time you hear the word "legacy" you should think along those lines. If large changes are easy, at least by some definition, you don't really have a legacy system.

He said that the best approach is to have a common date formatting function/class. He didn't mention that the system made it easy to do. The solution to the situation I mentioned is also a common date formatting function/class, somewhere. It's just that creating and designing this can be difficult under the circumstances.

given this statement of the problem, i'm on board with "just fix the immediate bug and move on".

words is hard. next time you're in sf, i can provide pints and whiteboards .

yuuuuuuuup.

i thought you were the guy who worked in the 100% pairing shop and generally thought it was good? maybe i'm mixed up on the latter clause?

i'll stick with the party line here: pairing is "always" better -- it dominates lone coding -- so the fact that there are two developers involved means they should pair.

the only reason i brought this up is i felt you were a little dismissive of clown's point and wanted to amplify that i, too, noted the failure to pair.

I would be more on board with pairing if it didn't revolve around synergy.

how about if it revolves around:

- better code quality, because two pairs of eyes catch more bugs and the "guilty conscience" factor

- less susceptible to interruption since one thread keeps context while the other is distracted

- ...

?

clown,

i think your expectations about workload are very influenced by working at a large erp enterprise. things move -- both technically and financially -- at a very different pace in that environment vs a startup or a small-to-medium niche software house.

but basically this:

i think we all agree that writing "better" code is generally but not always worth the effort, and disagree on exactly where to draw the line.

i do hope no one is waiting to ship code until it looks like it was written by knuth or schwarz or linus or guido or whoever.

shoe, i hope you're paying attention because candybar is spitting hot fire right now.

taking this in a slightly different direction:

mike mcd observes that poker players don't really remember pots they won, but they can tell you in great detail about pots they lost.

i like to think that i have generally done more good than harm in my development career. i've written my share of nice, maintainable, well-commented code. yet it is the atrocities i've committed which stick with me and keep me up at night.

openbsd is a fine operating system, but there was NO REASON to use it for those mission critical machines when we had no other openbsd machines anywhere.

updateCrontab.py: you helped us ship on time, you mostly work (except for that whole .pyc clobbering thing), but you are fundamentally terrible and they'll never manage to get rid of you.


what keeps you up at night?

The nagging feeling that no matter how much I learn about programming, I'll always be terrible at it...

Why would a broken python package keep you up at night? Isn't that par for the course?

indeed. but we can't all be bach/picasso/vonnegut/einstein.

zing!

Medium sized company (closer to small than big), not a large one. It was bootstrapped by the owner without much outside capital. He basically got a customer, built the required parts of the software (he had the architecture and overall design before going to find a customer) and then added customers one by (strategically) one that allowed him to add interesting pieces. I.e. first customer was only interested in production management, second needed project management, third mostly accounting etc.

One of our main competitive advantages was that we were way more agile than the huge companies. Obviously huge companies tend to be slow in general but the codebase was no small reason.
SAP code I have seen is a total disaster (even I can tell). ABAP is basically x86 as a language lol. Very backwards compatible but kludgy as hell heh

I did an in-house project where we brought in a consulting company for extra help where we paired 100% of the time. I don't remember how long it lasted but it was somewhere around 3-4 months. I came out of that thinking pairing is good lots of time but anything close to 100% is a waste of effort.

It just does't seem that two devs working together are going to get more done than working apart. Is it just a strategy to essentially pay two M quality developers for the work of one O quality dev?

alpo,

i don't actually want to launch into a pair programming debate, but proponents will tell you that pairing allows developers at any level to produce better code. given the high cost of bad code (as discussed at great length above), it seems like an easy ROI win in spite of requiring two devs instead of one.

http://en.wikipedia.org/wiki/Pair_pr...s_and_benefits

I'm not that interested really, just seems like there would be a quick answer to the most obvious question about it.

uh, there is, and i've provided it twice: the answer is yes. yes, it's better.