The Daily WTF: Curious Perversions in Information Technology

2013-05-02 Reply Admin

caffiend:
If he doesn't wanna do it, you've just gotta find yourself a "Merge Victim". It sounds worse than it is. It's just a dude with a good diff tool who is good at eyeballing code, and is across what all the people are doing in their respective branches. That does sound like a job for the team lead...

Or SCM. I'm that, and often am the merge victim. ;-) Sometimes I have to ask the people who made specific changes to sort it out, because they know why they made certain changes, but 99% of the time I can resolve the conflicts myself. We've got great developers who are accustomed to doing merging, but sometimes we have situations where it just isn't practical -- like the time we decided to spawn off a patch release that would have the fixes intended for the next release in it. It got messy, and the developers were under a huge time crunch, so it fell to SCM.

Source version control is never useless. Even on a tiny project it can save your butt. And it takes far longer to rant about it than it does to use the damn thing, unless your company has implemented it in a massively stupid way. (We all remember the tale of Codethulu, don't we?) Larrys are the people who, in the interest of getting the job done, leave you up a creek without a paddle two years later because they not only couldn't see the value of SVC but stubbornly refused to use it even when told it was their job to use it. Like working in a grain elevator without appropriate safety equipment, it's faster, but sooner or later something awful is going to happen.

2013-05-02 Reply Admin

“Our agile team needs some strong management, and we think you’re right for the job.”

Don't you love a slash and hack temp being sold as agile.

2013-05-02 Reply Admin

Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.

It kinda becomes a question of what direction people were given. I think the role of professional devs in these matters is to present the decision-makers with recommendations and their costs so they can make an informed decision; for example, explaining the long-term benefits and short-term costs of source control and the associated risks of not doing so. If Lisa was backing the team in making changes that she knew would take time then blame really does fall on her shoulders - who on whoever was telling her that there was sufficient time.

But it does sound rather like somebody high upstairs saw some figures and made some "decisive" decisions to "fix" the situation.

2013-05-02 Reply Admin

Comment? Ain’t nobody got time for that.

DrPepper · 2013-05-02 Reply Admin

Remy Porter:
PHB: What the hell is this? This is some programmer thing. I wanted to see your unit tests. Me: These are my unit tests. PHB: No, go do unit tests right- in IE.

I've seen this too. There is a terminology impedence mismatch here. Programmers think unit test means "testing a small piece of code"; managers think unit test means "test the order entry part of the application". To them, a unit is a unit of functionality, like a page in a web app.

2013-05-02 Reply Admin

Could not have said it better myself

If you want to guarantee a software project to fail select one or more of the following;

no requirements document
no testing plan
don't think out the deployment plan
don't use source control
don't have and don't enforce source code guidelines
ignore modern software development methodologies
don't document the software, modules and source code
hire, promote and listen to dufesses like Larry.

I have seen this many times. And every time time it leads to failure. It amazes me how management just doesn't get it.

Captcha Damnum; those damn knumbskull software hacks

2013-05-02 Reply Admin

Vanders:
Herr Otto Flick:
Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.
You can always add the unit tests later, when the money is coming in.
Out of interest, have you ever heard the phrase "Technical debt"?

Real unit tests (real... fully mocked unit tests...not integration tests) have a very low to negative ROI especially on young projects that dont have a stable set of business requirements.

Needing to pay back some technical debt is much better then never shipping a product.

The CI/TDD zelots are nearly as determental as the "dev on production" crowed when it comes to shipping an initial project. There has to be a balance of getting features out while not completely shooting yourself in the foot.

Has anyone ever worked in a place that has a fully functioning profitable product that was developed from the start using the strictest of development practices? (excluding giant corps that do multi million/billion dollar (Finantial/Medial/Military applications). Every tech company I have worked for has made its money by pushing a product out and are now hiring me to "do it right".

ObiWayneKenobi · 2013-05-02 Reply Admin

ronpaii:
“Our agile team needs some strong management, and we think you’re right for the job.”
Don't you love a slash and hack temp being sold as agile.

I see that mentality far too often. Managers love the idea of Agile; they get software every 2/3 weeks! But they forget about the high focus on testing, or refactoring, or pair programming, or having the customer be readily available, or not being able to add new features without removing something.. you know, all the things that make Agile possible.

My old job did this. The CIO decided we were going to be on a strict 3-week release schedule. What he didn't do was give us anything to facilitate those kinds of iterative designs, so what we had was releases that consisted of easy to fix bugs that we could do in time, so that we wouldn't have a release schedule with just 1 or 2 things in it.

I've seen this too. There is a terminology impedence mismatch here. Programmers think unit test means "testing a small piece of code"; managers think unit test means "test the order entry part of the application". To them, a unit is a unit of functionality, like a page in a web app.

This is why you have unit tests for developers and integration tests for managers, or use a tool like WATIN/WATIR or FitNesse to let managers verify that things work as expected.

2013-05-02 Reply Admin

Lerch98:
Could not have said it better myself
If you want to guarantee a software project to fail select one or more of the following;

no requirements document

no testing plan

don't think out the deployment plan

don't use source control

don't have and don't enforce source code guidelines

ignore modern software development methodologies

don't document the software, modules and source code

hire, promote and listen to dufesses like Larry.

I have seen this many times. And every time time it leads to failure. It amazes me how management just doesn't get it.

Captcha Damnum; those damn knumbskull software hacks

Thats not completely true... Ive seen a few projects that break some of thoes rules saved by Heroic Programing .

eViLegion · 2013-05-02 Reply Admin

mharrman:
Has anyone ever worked in a place that has a fully functioning profitable product that was developed from the start using the strictest of development practices?

Yes. Great products were produced on time.

mharrman:
Every tech company I have worked for has made its money by pushing a product out and are now hiring me to "do it right".

If they'd hired someone better than you first time round, they'd have made their money pushing their product out just the same, but wouldn't have had to hire you at all.

sprained · 2013-05-02 Reply Admin

caffiend:
IMHO if you happen to come onto a project which is behind schedule, over budget, with a crap code-base, no tests, no CI infrastructure, and funding problems, you really don't have time for anything but the basics.
Source control is the only bit of infrastructure with almost no cost and an instant payoff (honestly I don't even want to think about how people work without it, but anyway). It takes 5 minutes to install and it's already paid for itself the first time two people make a concurrent change to the same file.

As for "teaching people how to use source control", anyone who professes to be a professional software developer in 2013 whilst not knowing how to use even a basic version control system like SVN will only contribute a net-loss to your project.

My suggestion would be to immediately assign the offending individual a very important research project... Something to do with cat pictures and the internet.

Other than that, unit tests and CI are time-consuming to establish, and (at least initially) do detract from the immediate objective of having something to sell.

Sometimes you've gotta put commercial reality first. Once a project is that far down the track, refactoring it to be well structured, testable and automatically deployable is probably not a viable option anyway.

Just hack and slash (in a professional and responsible way) to get some revenue ASAP, then do a complete rewrite for V2.

Hey, i think this approach even worked for Facebook ;)

Agree with this (including the ranting), except I'd add an issue tracker to the list, and maybe separating development from production environments.

2013-05-02 Reply Admin

There's a little saying I've heard many times in this business: "We don't have time to do it correctly now. But we'll have time to fix it later."

Later, of course, never comes. We are so busy fixing all the things that are being wrecked by that out-of-control forklift running around the factory, that we just don't have time to figure out how to stop the forklift.

2013-05-02 Reply Admin

I then realized that being a developer, I have a superpower to create a product that can be replicated an infinite number of times. So, I started my own company.

2013-05-02 Reply Admin

eViLegion:
Yes. Great products were produced on time.

Any real examples?

eViLegion:
If they'd hired someone better than you first time round, they'd have made their money pushing their product out just the same, but wouldn't have had to hire you at all.

Yep and im sure facebook, youtube, and twitter... the top applications in their vertical did it that way... oh wait they didn't! They got a product out... got capital and then spent real time and money on building out a solid codebase and infrastructure.

The last company I worked at got bought out by a larger company and the owner and those of us with options made quite a nice chunk of change. Theres quite the profit to be made being the first to market.

Nice attempt at a childish insult though.

2013-05-02 Reply Admin

eViLegion:
Herr Otto Flick:
I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

I think you'll find that to most peoples understanding, if you're brought onto a project that is massively behind schedule, and you manage to create better code with less bugs, AND reduce your delay deficit, then you have delivered.

If you'd like a mathematical analogy: -10 + 5 > -10 even though -10 + 5 < 0.

You're one of those people who likes to blame the current administration of two years for mistakes made four years ago, right?

I'll avoid discussing specific IT methodologies or politicians here, but in general:

If the project was 6 months behind schedule when the new manager took charge and after he's been here for a year it's 3 months behind schedule, to say, "Look, since this guy was put in charge the project is 3 months behind schedule! He's ruining us!" is, of course, grossly unfair. Things are better than they were, so he's improving the situation. Maybe he's not improving it enough, maybe someone else could do better, but he's improving it. He's done better than his predecessor.

On the other hand, if the project was 6 months behind schedule when the new manager took charge and after he's been here for a year it's 9 months behind schedule, to say, "Hey, you can't blame him, the project was behind schedule when he started" is equally inaccurate. Things have gotten worse under his watch. Whatever the faults of his predecessor, he has not fixed the problem.

Whenever a new person is put in charge of something, I say, Give him a reasonable amount of time to put his policies or procedures in place. If things have been going badly for years it's unlikely he can fix it all in his first day on the job. But if after he's had a chance to actually do something, things are better even though they're not completely fixed, he deserves at least some credit. If things are worse than they were before, then it's his fault. Saying that things were bad when he took charge is not an excuse if he has not made them better. If your predecessor screwed things up so badly that you have no idea how to fix it, then you're not the right man for the job either.

Nagesh · 2013-05-02 Reply Admin

Ironside:
Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.
Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

You are right. Sometimes dirty/hack approach is not just sufficient, but necessary. I can go into a job telling them I'll cut to the chase, get the project done faster as I won't be p***ing about with all the trendy fashionable shit like TDD and Agile.

People like you have created messy shit holes that people like me at offshore are now managing.

ghosttie · 2013-05-02 Reply Admin

"Ain’t nobody got time for that" :)

2013-05-02 Reply Admin

caffiend:
Oh, and while we're on the topic of divergent branches, some prick who decides to do a global refactor->rename to correct something stupid like a spelling mistake in a variable name, annoying, but tolerable.

I am that guy. Since the app was ASP, and option strict was not turned on, people were attempting to use the variable with the correct spelling and getting null values.

Bad bad bad. :(

2013-05-02 Reply Admin

Herr Otto Flick:
...Mostly crap...

"Quality can come later down the line" "You can always add the unit tests later..."

Spoken by someone who has never tried to add quality to a non-quality product, or bolt unit tests onto code that wasn't designed to be tested (seriously, there's a reason that "Working Efffectively with Legacy Code" doesn't fit on a double-sided sheet of paper). Code written like this is a throwaway, full stop. It costs much more to struggle (and fail) to insert quality where it didn't exist before. How developers don't recognize the sunk cost fallacy is a mystery to me.

"...when the money is coming in. No money, no company, no development, no job."

Um, that company is always going to look at ROI, and it's not going to pay people to rewrite software that already creates a revenue stream. The crap software will stay crap, and the next software will be crap, because they'll the minimum amount of work to "get the job done", ignoring every process that has been born out of the last forty years of mistakes.

This isn't about process wankery, it's about actually developing a product that doesn't tarnish your company's image straight out of that gate. If you're struggling to keep your company afloat now, then you probably won't have a job six months from now.

ObiWayneKenobi · 2013-05-02 Reply Admin

Sanhadrin:
Herr Otto Flick:
...Mostly crap...

"Quality can come later down the line" "You can always add the unit tests later..."

Spoken by someone who has never tried to add quality to a non-quality product, or bolt unit tests onto code that wasn't designed to be tested (seriously, there's a reason that "Working Efffectively with Legacy Code" doesn't fit on a double-sided sheet of paper). Code written like this is a throwaway, full stop. It costs much more to struggle (and fail) to insert quality where it didn't exist before. How developers don't recognize the sunk cost fallacy is a mystery to me.

"...when the money is coming in. No money, no company, no development, no job."

Um, that company is always going to look at ROI, and it's not going to pay people to rewrite software that already creates a revenue stream. The crap software will stay crap, and the next software will be crap, because they'll the minimum amount of work to "get the job done", ignoring every process that has been born out of the last forty years of mistakes.

This isn't about process wankery, it's about actually developing a product that doesn't tarnish your company's image straight out of that gate. If you're struggling to keep your company afloat now, then you probably won't have a job six months from now.

EXACTLY. This kind of "git r' done" mentality is good only for throwaway projects because there's NEVER time to go back and fix what you hacked together. Once the app is done, there will be more features to add, more bugs to fix, and more work to do that will preclude a full stop "Okay it's ready for launch, now let's refactor/add testing/add quality to what we had to hack up to meet the deadline". How people still have this attitude astounds me because it constantly gets shown that the problems NEVER actually get fixed.

2013-05-02 Reply Admin

All of the following depends on the system, so...

There's nothing wrong with source control as long as it doesn't get in the way. And it can get in the way. When you need to be agile, source control is mostly there as a means for maintaining a backup should major changes go horribly, horribly wrong. For everything else, keep the document open and a big, fat undo stack (10,000 undo level is fine). If no one complains for a week after the change, then it is probably fine to close the document and commit the changes to source control.

There's also nothing wrong with working on a live system in a small team of two or three people. Around 6-7 developers on the same project, however, source control pretty much becomes mandatory to maintain sanity. And around a dozen or so devs requires more enterprisey setups with separate dev/test and production environments.

Vanders · 2013-05-02 Reply Admin

Spewin Coffee:
When you need to be agile, source control is mostly there as a means for maintaining a backup should major changes go horribly, horribly wrong.

Spewin Coffee:
There's also nothing wrong with working on a live system in a small team of two or three people.

I'll just assume you're kidding.

chubertdev · 2013-05-02 Reply Admin

C-Derb:
Could be worse.
How, you ask?

My current gig has gone bat shit crazy for SOA and decided that all configuration settings for all our numerous applications shall be stored in a centralized database accessed via a service call. It is working out great. I can page through all the production settings and see, in plain text, database connection information (usernames and passwords) for databases I didn't even know we had. The possibilities are endless!

All because, you know, SOA is totally hip. Web.config is for suckers.

Wait, do you work at my company?

chubertdev · 2013-05-02 Reply Admin

neminem:
I do kind of agree about unit tests. Sure, they're nice to have once they're working, but they are also kind of a pain to get working for anything even slightly complicated. I don't see a huge deal with only properly unit testing the truly critical parts of the system, if the goal is shipping a project that's already behind schedule. Testing: yes (you do have actual QA people on the team, right? If not, that's your bigger issue). Spending half your programmers' time writing tests for things that are most likely working, when they could be writing code? No. Save that for later. Not necessarily never, just not right now.
But you do need a testing environment that is neither the production environment nor each developer's personal computer, and holy mother of frack would I not want to work at a place with no bug tracker and where nobody used any sort of source repository. There's no possible way those could inhibit work getting done (well, unless they were just terrible... forcing everyone to use, for instance, VSS, that would be a real wtf, ugh. But barring that... I can't even imagine working without the ability to diff my code against an arbitrary slice of history of the file, for instance. How did I once live without that?)

You unit test the high-level methods, which references everything else.

Say that you have a class with three public methods, two private methods, and five properties.

Theoretically, the properties may support what happens in the public instance methods, and the private methods will be called by the public methods. So just testing the public methods should cover the vast majority of the class.

xaade · 2013-05-02 Reply Admin

Ironside:
Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.
Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

You are right. Sometimes dirty/hack approach is not just sufficient, but necessary. I can go into a job telling them I'll cut to the chase, get the project done faster as I won't be p***ing about with all the trendy fashionable shit like TDD and Agile.

No you are wrong.

If you startup a project, all that fashionable stuff will keep you on target. This project in the WTF was already doomed. There was no saving this project. There was no undoing the damage done. Management should have met with the stockholders to determine if they should just drop the project since no one was interested in seeing it to completion.

They made a scapegoat out of good developers and middle management, and now they are left with the same garbage that got them into the mess to begin with.

Besides, you don't put your internal tools devs mixed in with product devs, because then you have no way to acknowledge what benefits are coming from your internal tools. Even if actual work is crossover, you need to have a true cost-benefit of the internal tools separate from the product sales.

The problem with software engineering is that non of these internal tools and procedures have been codified in the actual cost of business.

No one hires a plumber, bids on a building project, etc. without determining an estimate. No engineer just starts hacking away at concrete to make those two big blocks of the bridge fit together because two teams built either side of the bridge.

We haven't codified the costs of planning software development as a distinct phase from actual building and deployment.

These are the true problems of software engineering. The vast majority of software engineering is not engineering at all, but just plain programming.

Nothing wrong with Agile, but it has to be weighed as the cost of estimate/engineering, and distinct from the cost of development.

2013-05-02 Reply Admin

This is the first time Nagesh, wrote a complete (well almost) sentence.

Bobrot · 2013-05-02 Reply Admin

It's too bad nobody caught the well-hidden reference. http://www.youtube.com/watch?v=bFEoMO0pc7k

2013-05-02 Reply Admin

Herr Otto Flick:
Y_F:
Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.
Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

No, it is a series of WTFs, but not on our skilled trio. First, it seems there was never a real estimate for the product. Second, they promptly started churning code without dev management, lead by a stupid senior dev. Third, they watched the whole thing go froim bad to worse, behind schedule and overbudget, only to 6-12 months later decide that some good management was needed. They called for it.

If the good devs push for improvement, like source control, unit tests, proper testing and such, they're doing their job. The project was already doomed, and they only did what could be done to set things straight, even if only to see a slightly better project fall off the cliff. And even like this, it's still probably better this way.

With Larry-like lead, if they ever manage to deliver something, will be some steaming pile of crap. It won't be documented, not tested, riddled with bugs and probably not backed up anywhere else. Sooner or later, their prod server would go up in smoke along with the whole single copy of their product, or simply it would grind to a halt, unable to perform maintenance, fix bugs or add new features. The client would start using and relying on a product that soon would give them lots of trouble. It would do more harm than good, either because it does not work properly, barely works or some sunny morning it simply stops to work.

Do you honestly think this is a better outcome?

If you can sell it, keep the company operating, keep you and your colleagues in jobs, then yes. Version 1 doesn't have to be perfect, but it needs to work, it needs to be delivered in time for the company to make money from it.

Quality can come later down the line, if you obsess over quality whilst the company disintegrates around you, you've failed.

As I've said, Larry is a tool. VCS adds a lot to a project, and doesn't really cost you anything. Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.

You can always add the unit tests later, when the money is coming in. No money, no company, no development, no job. Show me the money.

If Version 1 is utter shite, then no one is going to want to use Version 2, no matter how many pictures of cute kittens you add.

And as for adding features vs quality control, what good is having half a dozen more features if they're all half baked and don't work worth a damn? This is the difference between Microsoft's approach and Apple's. Microsoft goes for the bullet points on the box. Apple might leave some features off of version one, but that's because they recognize that you only have so much time in the day, and you can either spend that time making some features really, really good, or half-assing some other features.

2013-05-02 Reply Admin

caffiend:
ObiWayneKenobi:
But in a small team (my main experience) it's ridiculous. You get one guy, usually as senior like Larry in the story, who pushes against it because he doesn't understand and doesn't want to understand it.
If he doesn't wanna do it, you've just gotta find yourself a "Merge Victim". It sounds worse than it is. It's just a dude with a good diff tool who is good at eyeballing code, and is across what all the people are doing in their respective branches. That does sound like a job for the team lead...
One bit of good advice tho, if you can be a Nazi about anything, ATOMIC COMMITS. Don't commit you're days work when you go home at 5, do it in 3 or 4 commits, each targeted at a feature. If it's done well, it can make the whole divergent branch thing a lot less painless. Plus, it's not retarded.

Oh, and while we're on the topic of divergent branches, some prick who decides to do a global refactor->rename to correct something stupid like a spelling mistake in a variable name, annoying, but tolerable.

BUT THIS FUCKING THING TAKES THE CAKE.

Yeah, just re-arrange every method in the goddamn file, arbitrarily, then check in a 2 line change. Good luck finding what it was.

Agreed, however, running something like that on a commit hook would be nice to keep the code somewhat consistent.

ObiWayneKenobi · 2013-05-02 Reply Admin

Herr Otto is right... in extreme fringe cases. What often happens is you never have time to go back to add tests later "when the money is coming in", because there will be other things that will bring more money in that push testing and good practices to the curb. That's why it's so important to have quality from the start; if you fall into the trap of "Spending time making the code good won't let us sell it fast enough" you're never going to be able to recover and get the time to do it right again.

I have never seen any place actually address quality concerns in a rational manner when there was a somewhat valid excuse to not address quality at the start. It's always been ignore quality now, and then ignore quality later because you've already shown that you can put out a "successful" version of the software without quality, so all of that high-falutn' quality stuff is rubbish.

2013-05-02 Reply Admin

Herr Otto Flick:
Quality can come later down the line, if you obsess over quality whilst the company disintegrates around you, you've failed.

And we have found the real wtf. Doing it right saves time. Doing it wrong takes longer.

Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at

I don't think that what this means is what you meant, but I agree with this. You can work a lot faster if you're not trying to untangle regressions - that is, if you write good unit tests.

You can always add the unit tests later

No. Just no.

2013-05-02 Reply Admin

Spewin Coffee:
All of the following depends on the system, so...
There's nothing wrong with source control as long as it doesn't get in the way. And it can get in the way. When you need to be agile, source control is mostly there as a means for maintaining a backup should major changes go horribly, horribly wrong. For everything else, keep the document open and a big, fat undo stack (10,000 undo level is fine). If no one complains for a week after the change, then it is probably fine to close the document and commit the changes to source control.

There's also nothing wrong with working on a live system in a small team of two or three people. Around 6-7 developers on the same project, however, source control pretty much becomes mandatory to maintain sanity. And around a dozen or so devs requires more enterprisey setups with separate dev/test and production environments.

While a small team can work directly in production, there's usually almost no cost to doing things right.

And really, there's no excuse for not using version control.

Kuba · 2013-05-02 Reply Admin

Ironside:
Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.
You are right. Sometimes dirty/hack approach is not just sufficient, but necessary. I can go into a job telling them I'll cut to the chase, get the project done faster as I won't be p***ing about with all the trendy fashionable shit like TDD and Agile.

I don't know what kind of an alternative reality you two live in, but to me solid source control and even just a minimum amount of tests is the only way to be sure that the steaming pile of shit I might be working on has, in fact, any chance of working at all. The more hackish your approach, the more you need solid version control and at least some basic tests.

I've used this approach quite effectively while working on various homework projects in the graduate school. Nothing beats a version control and a makefile that such that a checkout of a 'last good' tag followed by a "make submit" will generate the pdf and any needed attachments and email it or upload it where it needs to be mailed/uploaded, a minute before the deadline :)

2013-05-02 Reply Admin

Him and that cockamamie source-control stuff.

That's some M. Night Shyamalan-level stuff right there.

2013-05-02 Reply Admin

Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.
Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

Your job is to write MAINTAINABLE software. Maybe there are some best practices that can be (temporarily) thrown away during a crunch, but version control speeds up development in both the short and long term. Bug control, testing etc. are absolutely necessary if you want to have a mature stable product. But, hacking in fine if you are just writing a proof of concept.

2013-05-02 Reply Admin

neminem:
and holy mother of frack would I not want to work at a place with no bug tracker and where nobody used any sort of source repository. There's no possible way those could inhibit work getting done (well, unless they were just terrible... forcing everyone to use, for instance, VSS, that would be a real wtf, ugh.

Or, even worse, iRational ClearCase!

2013-05-02 Reply Admin

JimLahey:
"What's the point of unit tests, I know my stuff works"

Here the attitude is, and I shit you not, I was told this, "unit testing, designing code, modularity, asserts and all that stuff sounds good on paper, but I spend so much time trying to fix all of my bugs that I have no time after to go back and add this stuff"

Umm.

2013-05-02 Reply Admin

chubertdev:
neminem:
I do kind of agree about unit tests. Sure, they're nice to have once they're working, but they are also kind of a pain to get working for anything even slightly complicated. I don't see a huge deal with only properly unit testing the truly critical parts of the system, if the goal is shipping a project that's already behind schedule. Testing: yes (you do have actual QA people on the team, right? If not, that's your bigger issue). Spending half your programmers' time writing tests for things that are most likely working, when they could be writing code? No. Save that for later. Not necessarily never, just not right now.
But you do need a testing environment that is neither the production environment nor each developer's personal computer, and holy mother of frack would I not want to work at a place with no bug tracker and where nobody used any sort of source repository. There's no possible way those could inhibit work getting done (well, unless they were just terrible... forcing everyone to use, for instance, VSS, that would be a real wtf, ugh. But barring that... I can't even imagine working without the ability to diff my code against an arbitrary slice of history of the file, for instance. How did I once live without that?)

You unit test the high-level methods, which references everything else.

Say that you have a class with three public methods, two private methods, and five properties.

Theoretically, the properties may support what happens in the public instance methods, and the private methods will be called by the public methods. So just testing the public methods should cover the vast majority of the class.

Unit tests don't require more hardware. You can test your mock objects, like SQL result-sets right now.

Waiting for the SAs to build another SQL server or an Apache instance to run integration tests, means you may not test at all.

Matt Westwood · 2013-05-02 Reply Admin

Derek:
Dave H:
Sparticus:
I am Jeffery!

We're all Jeffery.

I'm a Derek. Unlike Jeffery, Derek's don't run.

But did they make you eat chuck?

Matt Westwood · 2013-05-02 Reply Admin

mharrman:
Vanders:
Herr Otto Flick:
Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.
You can always add the unit tests later, when the money is coming in.
Out of interest, have you ever heard the phrase "Technical debt"?

Real unit tests (real... fully mocked unit tests...not integration tests) have a very low to negative ROI especially on young projects that dont have a stable set of business requirements.

Needing to pay back some technical debt is much better then never shipping a product.

The CI/TDD zelots are nearly as determental as the "dev on production" crowed when it comes to shipping an initial project. There has to be a balance of getting features out while not completely shooting yourself in the foot.

Has anyone ever worked in a place that has a fully functioning profitable product that was developed from the start using the strictest of development practices? (excluding giant corps that do multi million/billion dollar (Finantial/Medial/Military applications). Every tech company I have worked for has made its money by pushing a product out and are now hiring me to "do it right".

Yes.

Many years ago I worked in a team of 6 developers who were designing a ballistic gunfire control system for on board ship. We used JSP/JSD, modular design including unit tests, based on a domain simulator which we just happened to have which had evolved over the course of some years, and a rigorously structured suite of documentation specifying its mathematical design. It was the first (worldwide) commercial shipping of a program written in Ada. We delivered it within budget and to the timescales. We plugged it in, turned it on and it worked first time.

It was admittedly military (naval, specifically) but it was not multi-million dollar - IIRC it retailed at a modest 6 figures. We delivered a few more of these babies.

2013-05-02 Reply Admin

Getting it out the door, with the intention of fixing it in V2, is the cardinal doctrine of the Church of the Spaghetti Monster. Management that is SNAFU enough to allow slap-dash project development is too SNAFU to ever see value in refactoring. One V1 is "good enough", You will be put to work doing something else. The app will be patched when there is a crisis, but only enough to avert the crisis.

Captcha jumentum: "Jumentum is a Robin Williams film, remade for a Latin-speaking audience."

havokk · 2013-05-02 Reply Admin

Ironside:
I can go into a job telling them I'll cut to the chase, get the project done faster as I won't be p***ing about with all the trendy fashionable shit like TDD and Agile.

"So, logging company, you are a long way behind on your deliverables (logs). That's OK, I'll cut to the chase and cut down trees faster as I won't be pissing about with all the trendy fashionable shit like chainsaws and front-end-loaders and mechanical log lines. An axe was good enough for me when I started as a lumberjack so I refuse to use anything else."

2013-05-02 Reply Admin

Herr Otto Flick:
Y_F:
Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.
Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

No, it is a series of WTFs, but not on our skilled trio. First, it seems there was never a real estimate for the product. Second, they promptly started churning code without dev management, lead by a stupid senior dev. Third, they watched the whole thing go froim bad to worse, behind schedule and overbudget, only to 6-12 months later decide that some good management was needed. They called for it.

If the good devs push for improvement, like source control, unit tests, proper testing and such, they're doing their job. The project was already doomed, and they only did what could be done to set things straight, even if only to see a slightly better project fall off the cliff. And even like this, it's still probably better this way.

With Larry-like lead, if they ever manage to deliver something, will be some steaming pile of crap. It won't be documented, not tested, riddled with bugs and probably not backed up anywhere else. Sooner or later, their prod server would go up in smoke along with the whole single copy of their product, or simply it would grind to a halt, unable to perform maintenance, fix bugs or add new features. The client would start using and relying on a product that soon would give them lots of trouble. It would do more harm than good, either because it does not work properly, barely works or some sunny morning it simply stops to work.

Do you honestly think this is a better outcome?

If you can sell it, keep the company operating, keep you and your colleagues in jobs, then yes. Version 1 doesn't have to be perfect, but it needs to work, it needs to be delivered in time for the company to make money from it.

Quality can come later down the line, if you obsess over quality whilst the company disintegrates around you, you've failed.

As I've said, Larry is a tool. VCS adds a lot to a project, and doesn't really cost you anything. Religiously writing unit tests to validate the correctness of your code adds quality, but it also doubles or triples the rate that you can add features at - you're spending all that time fucking about with unit tests when you could have added the next feature.

You can always add the unit tests later, when the money is coming in. No money, no company, no development, no job. Show me the money.

I sort of can see that hacking and slashing to deliver a project is necessary, however the project still has to be of sufficient quality not just to sell to the customer to stay afloat, but to convince them that Version 2 is worth the buy further down the track.

As for your point on Unit Tests taking time away from adding features - if you're really in the sort of shithole where you need to deliver something to fund future versions, then I'd suggest you shouldn't be focussing on adding features anyway - they're just gonna make an already pretty risky deployment even more dangerous....

If you ever are in the situation where it's "cut corners to deliver something...anything" then you really have to start questioning whether you really want to deliver anything at all. Releasing a bug-filled product migth get you some $$ in the short term (because the customer doesn't know better) but it seriously risks losing any credibility when you want to deliver an improved version - or (worse still) different software altogether. In this situation, I think the idea would be make fast bucks selling the buggy version, then start looking to bail out buy seliing your "very successful operation" before the backflak....

2013-05-02 Reply Admin

Mitch:
...snip...

addendum to the bit above:

Like with anything else, you need to achieve a balance between quality and functionality - you'll rarely (if ever) develop the absolute best quality product and it's important to consider Cost of Quality vs Cost of Poor Quality (why am I having a Six Sigma flashback - or was it CMMI?)...

<offtopic> NB: Similar goes for security. You need a balance between security and functionality. The most secure computer is one that isn't turned on - but it's not much use to anyone. </offtopic>

2013-05-02 Reply Admin

EvilSnack:
Getting it out the door, with the intention of fixing it in V2, is the cardinal doctrine of the Church of the Spaghetti Monster. Management that is SNAFU enough to allow slap-dash project development is too SNAFU to ever see value in refactoring. One V1 is "good enough", You will be put to work doing something else. The app will be patched when there is a crisis, but only enough to avert the crisis.

Depends what you mean "get it out the door"... Some things like full code coverage unit tests and TDD can be very time consuming in the short term.

However:

Using version control
Writing high level integration tests
Following proper design patterns
Following SOLID/Basic Architecture principles
Following Coding Guidelines
Simple/Quick Peir review.

Will keep a project from becoming spaghetti with little to no additional overhead vs "hrrr...get er don!" when working with competent developers. This should also leave the code loosely coupled which should make implementing unit tests to prevent regretion trivial.

Developers do not need unit tests/TDD to write good code, and unit tests/TDD do not make bad developers write good code. When all other procedures are being properly observed all unit tests accomplish is alerting you when someone is repeating the same mistake twice (unit tests do not magically test all edge cases even at 100% code coverage).

On the comment about management/refactoring... it is the job of the team lead/ team architect to explain to management how not refactoring will effect there bottom line/timeline.

I get to use a line like this all the time: "Feature X will take 30% longer to be completed because we need to refactor system Y... if we dont all dev work henceforth will suffer a additional 20% time overhead from technical debt."

If they complain... or object... "If you think you can find someone who will be able to do this better and faster then me you should fire me and hire them".

PS: Note I dont think unit tests/TDD is bad... just not a cache all solution.

2013-05-02 Reply Admin

jay:
eViLegion:
Herr Otto Flick:
I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

I think you'll find that to most peoples understanding, if you're brought onto a project that is massively behind schedule, and you manage to create better code with less bugs, AND reduce your delay deficit, then you have delivered.

If you'd like a mathematical analogy: -10 + 5 > -10 even though -10 + 5 < 0.

You're one of those people who likes to blame the current administration of two years for mistakes made four years ago, right?

I'll avoid discussing specific IT methodologies or politicians here, but in general:

If the project was 6 months behind schedule when the new manager took charge and after he's been here for a year it's 3 months behind schedule, to say, "Look, since this guy was put in charge the project is 3 months behind schedule! He's ruining us!" is, of course, grossly unfair. Things are better than they were, so he's improving the situation. Maybe he's not improving it enough, maybe someone else could do better, but he's improving it. He's done better than his predecessor.

On the other hand, if the project was 6 months behind schedule when the new manager took charge and after he's been here for a year it's 9 months behind schedule, to say, "Hey, you can't blame him, the project was behind schedule when he started" is equally inaccurate. Things have gotten worse under his watch. Whatever the faults of his predecessor, he has not fixed the problem.

Whenever a new person is put in charge of something, I say, Give him a reasonable amount of time to put his policies or procedures in place. If things have been going badly for years it's unlikely he can fix it all in his first day on the job. But if after he's had a chance to actually do something, things are better even though they're not completely fixed, he deserves at least some credit. If things are worse than they were before, then it's his fault. Saying that things were bad when he took charge is not an excuse if he has not made them better. If your predecessor screwed things up so badly that you have no idea how to fix it, then you're not the right man for the job either.

I don't think it's quite that simple

If when someone walks into a project it's 6 months behind after 12 months, and in the next 12 months (under their charge) slips another 3 months, then although they haven't fixed the issue they may have started to real in the slippage (or things might have just settled down). Sometimes it's not as easy as reversing the trend immediately. When you're reversing a train, you apply breaks and it gradually stops going backward, and then you can flick the reverser and go forward....

EG: a project has taken 12 months and is already 6 behind...(ie it should have been at this point in 6 months not 12). Suppose At the end of the 13th month, we are 6 months 10days behind - going at the old rate (of taking twice as long) we would have been more than 6 months 2 weeks behind... Suppose after 14 months we are 6 months 19 days behind...we're still slowing the slippage... 15 months and 6m 26days....vs 7.5 months 16 months: 7 months vs 8 months 17 months: 7 months 4 days vs 8.5 months 18 months: 7 Months 6 days vs 9 months 19 months: 7 Months 7 days vs 9.5 months 20 months: 7 Months 7 days vs 10 months....etc...

Sometimes, winning is reducing the slippage. Of course, eventually we want to eliminate the slippage altogether (and reverse it if possible) but a lot of it depeneds on miulestones not being set in stone...

I suppose in an ideal world, when you are appointed to a project that is behind, the first step should be to renegotiate the timeline...so you;re never in arrears. In reality, even if we wipe off the original amount of time we're behind, there'll still be a certain expectation that the various milestones still take the same amount of time - just with a different start date...

Captcha: ridiculudus

2013-05-02 Reply Admin

Nagesh:
Ironside:
Herr Otto Flick:
Michael, Lisa and Jeffrey are the WTF here. As a developer, it is not your job to do awesome software development, it is your job to deliver what the company needs. This company needed their software written. Like 6 months ago.
Michael and Jeffrey instead spend their time making sure that the pieces that they have written operate perfectly. This is not the goal. The goal is deliver working, or semi working software fast enough that you do not burn through your capital before realising sales.

They ended up delivering something the company couldn't sell. They should have been going like shit off a shovel trying to deliver what the company needed, not what they wanted to do.

I'm not saying Larry was the solution, he sounds like a tool, but whomever of Michael, Lisa or Jeffrey that submitted this is far too proud of their dev skills whilst failing to deliver.

You are right. Sometimes dirty/hack approach is not just sufficient, but necessary. I can go into a job telling them I'll cut to the chase, get the project done faster as I won't be p***ing about with all the trendy fashionable shit like TDD and Agile.
People like you have created messy shit holes that people like me at offshore are now mangling.

FTFY

2013-05-02 Reply Admin

Spewin Coffee:
All of the following depends on the system, so...
There's nothing wrong with source control as long as it doesn't get in the way. And it can get in the way. When you need to be agile, source control is mostly there as a means for maintaining a backup should major changes go horribly, horribly wrong. For everything else, keep the document open and a big, fat undo stack (10,000 undo level is fine). If no one complains for a week after the change, then it is probably fine to close the document and commit the changes to source control.

There's also nothing wrong with working on a live system in a small team of two or three people. Around 6-7 developers on the same project, however, source control pretty much becomes mandatory to maintain sanity. And around a dozen or so devs requires more enterprisey setups with separate dev/test and production environments.

The second Billy Goat stepped onto a bridge...only to be met by a hungry troll, "I've seen some finer grass, so please let me pass" "But I want to eat you up", said the troll...

2013-05-02 Reply Admin

Aside from the attrocious spelling (I'm not surprised there was a sub-argument about missplet variable names) I find it a bit frightening at the willingness of people to cut corners.

Recently I built a house - well, I didn't, I paid someone else to do it. I wouldn't have been very happy if after moving in they said "Yeah, we didn't have time to build the frame properly, so we'll come back (in a couple of moinths (at your expense) to fix that up - oh, and the leaking taps we put in - we didn't think to check whether they worked because it was too hard to actually switch the mains water on, and by the time we did it was kinda too late. Actually, come to think of it, a couple of your doors don't hang straight either - but we didn't have time to get a spirit level out to make the frames square - you did want it built by April, after all, and that was more important than doing stuff properly (we don't know how we'll realign the windwows - maybe you just live with that, mk?".

While there is a certain specialisation in IT that is perhaps unique to the field (I'm not always convinced) the bottom line is still the same - things should be planned properly - and in the IT world this includes being comfortable that stuff works. This fundamentally includes using adequate checks and tests to minimise (read: attempt to eliminate) any chance of mistakes being made and a substandard product being delivered.

Perhaps one of the biggest issues in IT is that intelligent people (or at least those perceived to be intelligent) are at the bottom of the chain, not the top. This means they always think they know better. A brickie gets told to brick a house, and he whacks bricks and mortar around and gets the job done. A code monkey gets told to implement something and he takes a free license to redesign/recreate every working library known to man....DateTime, Data Structures, etc, etc, etc - unless you are very, very experienced and actually understand fully what you're doing, just use the existing ones - they have evolved from people a lot smarter than you working on them for squillions of years...and they've probably been tested far more extensively than you'll ever have time for....

captcha: commoveo - since my hair started falling out, I have started to wear a commoveo

2013-05-02 Reply Admin

secundum:
Dave H:
Sparticus:
I am Jeffery!

We're all Jeffery.

I'm Jeffrey, and so is my wife.

I'm not.

Slacking Off

Leave a comment on “Slacking Off”