- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Oh my, what a slacker :(
Admin
Quality starts from the top down. If management comes from a used car lot "we only want sales" perspective then the rest of the company will act that way.
Sadly, with pressure on money concerns, more and more companies will go this way. ... I hope they fail short term as well.
Admin
Sadly I've encountered a similar mentality. I was fired last July from a job because our "Larry" didn't like the things that I was pitching such as actually making good use of source control, having actual testing, and scoping the app properly instead of adding more work every time the boss wanted some new thing added to our current "sprint". Our CIO, unlike Lisa in the story, bought every word about how bad these things were from our Larry and got rid of me because my constant pushes for change weren't sitting well with him.
The only thing that caught me off guard here was that management actually listened to the new guy's suggestions over "Larry" the senior dev, instead of telling him to sit down and shut up, if not firing him for wanting to change things. I think that outcome is more common in environments.
It sounds though like everyone got what they wanted. Michael and Lisa, as managers, probably had no issues getting new jobs. Jeffery seems like a bright guy so he probably did well himself (probably for more pay too, and now he has lead experience). Even scumbag Larry got to keep his job and run the company into the ground without any of that high-falutin' modern development stuff, and since he's the manager now he can squash any newbie developer who wants to use source control or bug trackers.
Admin
I really enjoyed this story!
Admin
Isn't this called DevOps?
Admin
Mayhap we could start a couple other sites and name them The Daily PHB and The Daily Wally so that TDWTF can focus on code WTFery.
facilisi: "I biss my songue, buss this facilisi has no docsor."
Admin
No no no. On the contrary. We need much more of this - even though it was a very sad story (I miss the part where the company goes bankrupt or something).
Admin
How about we just rename it to The Daily Shit that didn't Happen?
Admin
I am Jeffery!
Admin
The sad part is that things will go downhill, and management will never know why...
... why, o Lord, is there such a vicious cicle of life and death cursing all IT projects? Is smart management just a legend?
Admin
We're all Jeffery.
Admin
This! Stories are much more entertaining, and a bit educational too. To see oh-my-god-my-eyes-bleed code, I just need to Alt+Tab to my open IDE.
Admin
Smart management is an oxymoron...or maybe just a moron?
Admin
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.
Admin
I'm a Derek. Unlike Jeffery, Derek's don't run.
Admin
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?
Admin
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.
Admin
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?
Admin
Sadly, by the time the end of this story came it was a lose-lose situation. Even assuming theyntried to make the best of it and retained Jeffrey instead of Larry, he would have had to do the role of team lead as well as all management work (because "management is 100% overhead" is usually bullshit) and would have burned out anyway.
Admin
It's never a smart idea to cut corners, even on a project that's behind schedule. Cheap hacks are never the answer. You triage the situation, set up a proper environment to facilitate better change, and then take care of the most critical issues as soon as possible (hacking if you have to but making strict notes to refactor later).
People like Larry are a cancer on companies since they almost always have someone's ear, but are useless and ignorant of anything modern. Modern techniques make it so you don't fall behind schedule in the future, but if you ignore them and fall behind and then introduce them, the blame doesn't lie on the new things like so many clueless idiots try to pull.
Admin
Well, get up a tree or something!
Admin
So you're basically saying that proper QA, CI, SCV, etc. Are overhead which in turn will make any software project delivery longer. It's better to simply get your server running and start coding in it... yeah, try that in the real world to see how it ends. All that is simply stuff which software engineers made up so they would get a job.
Anyway, starting this sort of project without a proper manager/project owner who knows how to deliver proper and maintainable software in time is ridiculous.
Admin
Admin
What... no comments yet about the Facebook bashing in the "story"? I thought they recovered well...
Admin
The stuff that Jeff was pushing (Source control, CI, unit tests, scripting) are all good DevOps tools and methods. The methodology that Larry was pushing is technically known as "Clusterfuck"
Admin
Got people like this at our place, fortunately none in management and in the minority at that.
"What's the point of unit tests, I know my stuff works"
"If I write a test then I'll have to change it when I change my code"
"the problem with unit tests is that you need to learn a whole testing framework"
"a testing framework, can you really trust that?"
"Tests take too much time, we could be programming instead"
They're the same group who don't trust WCF, Entity Framework, NHibernate, anything off CodePlex or the entire .net Framework for that matter. They'd rather use the framework they don't trust to reimplement other parts of the framework they don't trust.
3 man months spent rewriting ADO.net, but not as well.
Don't ask me how long they took building their own localisation component or how long it took someone to implement a SOAP service from scratch using only HttpWebRequest and string concatenation whilst ignoring WCF and any .asmx options.
.net config files that don't actually contain the config, rather a single file path in appSettings to an xml file which contains the actual config. someone seriously asked me if I could migrate my WCF service config from web.config to the xml file, because "it's cleaner that way".
fuck.
Admin
The ship's sinking and there's a hole in the hull below the water line. Patching the hole is simply going to prevent us from delivering- we just have to bail out the water faster.
Admin
I'm Jeffrey, and so is my wife.
Admin
Oh god yes. It seems like every company I interview with is full of people like this. Use a mature tool that's been out for years to help us write better code? Nah we'll just use stored procs like it was 2000 and write our own data layer around ADO.NET. Unit tests? You mean poke around in IE, right?
I can kind of see the different config files depending on what you need, but the rest is indicative of a lot of bad things and it seems like in Tampa those are the only places that exist.
Admin
I swear this happened to me: PHB: "Did you run unit tests?" Me: "Not yet." PHB: "Can you give me some screenshots while you do it?" Me: "Um... okay."
I push the button to run unit tests, screencap the report, and send it along.
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.
Admin
I can't. Not when they hold things as complicated as boolean flags to turn application features on or off. Or connection strings and passwords, because they're no longer in a standard .config encrypting them like you easily can with a standard .config "would take too long". So they're in plain text.
Admin
Ugh. Point taken. That's just ugly. I meant more like how you can have a ConnectionStrings.config or a Local.config for override settings.
Admin
Especially because if you use a single config file (app or web) you:
XDT can be used on other XML files if you want to customize your build process, but you might as well tie into the existing pipeline.
Admin
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 ;)
Admin
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.
Admin
But they are tasty.
Sorry, that remark was in Bad Taste :-)
Admin
I've seen so many people who have no idea of anything beyond comitting it's not funny. Ask about branches/tagging and you get a blank stare.
It's not as bad as the anti-ORM/sprocs for everything crowd that seems more resistant to change, but still a bit ridiculous.
Admin
Admin
In a largish team, having a few (minority emphasized) members who aren't totally comfortable with the concept of branches and merges isn't the worst thing in the world. Just so long as they do atomic commits like "fixed issue #whatever", or "Implemented feature card blahblah" it's manageable, albeit annoying.
Admin
And how do you test? clicking around in IE? Do you really believe that is faster and more efficient than unit tests?
if you "test" say an insert, you have to manually enter the data and then manually look in the database if the data is actually there. Thats is never faster.
I can live with not testing properties or setters and getters and not testing every single convoluted edge-case. But at least 1 test that checks the new method actually does what you want it to do with the correct input helps a lot.
Admin
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.
Admin
And in the time where you debugged the errors created in the first feature created by the second feature, you implement the third and fourth feature. It really does double or tripple the rate at which you can add (working) features
Admin
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.
Admin
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.
Admin
The way I read it, they were already behind and they were behind because of Larry. The new process sped things up and it was too little too late, but the people that sped up the process late in the game were the most expensive and first to go.
Admin
Admin
This sounds exactly like my last company, I ended up there after "Larry" took over.
captcha: nibh, like cacao nibs, but better.
Admin
Wouldn't surprise me if he didn't, or if he's one of those devs that keep putting off the technical debt (e.g. "We don't have time to refactor the code, the execs wants Feature X done in a month!") until the company experiences technical bankruptcy.
Admin
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?)
Admin
This story nearly made me cry... Luckily enough I've never been in an actual situation like this, or I would have actually cried.
CAPTCHA: venio Many venio(l) sins in this one.