The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Doctors, lawyers, politicians, plumbers, mechanics, BOSSES, etc.....When I was young I had this notion that people were generally competant, say, 99% of the time. Now that I have seen what there is to see, my estimate is less than 50% are competant and almost none should be completely trusted.
The place I work at uses the same one size fits all thinking (granted it works well for one the original), never stops to think, hey looks like we're working on a different application and different requirements. All that matters is to use the same shoe everywhere (they're kind of proud of it too). The thing is it is team lead's decision to make everyone put on the same shoe everywhere. I would like to argue but I've gone to a phase where I just don't give a sh*t and I have started looking for a new job opportunity.
he did it just because he could argue he was 'right'.
Same thing happens with the guy I work with, occasionally he'd come up with these great ideas and would never stop bragging, but most of the time he is just arguing for his shoe which doesn't fit very well, but wins the fight almost every time because the guy can argue. Sometimes I'd be able to convince him if I find a not so critical flaw. If however there's only a critical one he'd simply shake his head say "You don't understand it", and come up with a contradictory argument to say otherwise.
Agree. It truly is amazing how many people with no real aptitude for programming choose it as a career. Then again, without them, I'd have a lot fewer contracts cleaning up their messes. So...for me, not sure if bad programmers are a good thing or a bad thing
Your current contracts are about cleaning up a mess, not your favorite pastime I think.
Without those bad programmers your contracts would be about building cool new functionality in well-built systems that are ready for the next level.
Functionality that's not possible or too expensive in the current software because it's such a mess.
Fir point although I don;t think our collective gripes are about software, per se, rather the gift wrapping it all seems to come with now mostly forced upon people by gullible managers. Still, each to their own.
Keep your friends close. Keep Kill your enemies closer. The End
Ranting wasn't as much fun as I hoped. I tried it. I don't think its the thing for me after all.
Your rant is too verbose, lacking insults, too intellectual, and not sufficiently emotive. Here's a rewrite:
Software methodologies implies people have the intelligence to actually come up with logical methods. Instead management creates arbitrary rules in knee jerk reactions resulting in arbitrary software ideologies that we become mindless slaves to, genuflecting to the process god hoisted onto his throne, only to be cast into oblivion and replaced by a new god by the next manager and his particular psychosis.
OK, still too intellectual, probably still too verbose.
I've been fortunate to have a couple of good technical managers over the decades...they're almost as much of a rarity as unicorns. Instead of enforcing policy, the better managers protected the team from politics, helped establish a direction when there were competing visions within the team, and just generally made sure we had the resources we needed to complete the work. Those were fun jobs and unsurprisingly those teams were very productive.
So, my experience, you simply put together a few talented engineers with a supportive manager and great things happen. Hmmm...that seems like an easy formula...maybe I should jot down a few guidelines, add a few rules, and write a book...what could go wrong?
The one thing that has determined the success/failure of projects I have worked on has been the quality of communication between people in the team.
It's interesting you mention that. I say that because have you heard what one of the guys that came up with agile wanted to call it instead of agile? Conversational development, IE the way you do anything is to have a conversation between the involved individuals. Of course it also has to be stated that you can't have a conversation if one side doesn't respect the other, in that case you generally end up with a lecture. Unfortunately with a name like "Agile" plus all that dogma in the manifesto the core idea which you've hit upon gets lost doesn't it?
There's definitely something of a cargo cult built around some methodologies.
I recently worked with an ardent TDD disciple who would get a little upset with my view that TDD might have its place but that it wasn't the panacea for all things.
I didn't get to see any of his work until after he left. Sure, all the unit tests were passed, but sadly, it wasn't quite the same story when it came to user tests. In fact, it couldn't have been more different. Everything was about as dysfunctional as it could possibly be.
There's a dangerous belief at work there, namely: "I am doing this properly so I have no need to worry about anything going wrong." It's every bit as ill-founded as the idea that if we build the runway, the great iron bird will arrive laden with goodies, and its equally fallacious in that it comes with that implicit guarantee - "this is the way and the way cannot fail."
Once we remove the possibility of failure from our expected outcomes (probably something that various new age barkers would actually advocate), we're left in a state where we stop thinking about how we'll deal with the inevitable. Rather than planning how we'll bubble up our exceptions, we just shrug our shoulders and say "Exceptions? What exceptions? There won't be any exceptions!"
It's this complacency that tends to make rigid devotion to a methodology a very dangerous thing.
The wise course is to cherry pick these things to suit our projects. A few core unit tests are obviously a good idea in many situations, so let's use them but the minute that we start to think that we've come across a fool-proof way to write bug-free software, we're off in the woods with the fairies and the unicorns and we haven't got a cat in hell's chance of coming back in one piece.
That's more or less what I'm advocating. I simply don't believe that any methodology is one-size-fits-all. There are a couple of methodologies out there that suggest reasonable goals.
I view these goals as aspirational. I make an honest effort to achieve them. However, if I find some goal is a bad fit for a specific project, I'm willing to set aside that goal.
In general, I'm very leery of words like "always" and "never". In my experience these words are always wrong and never lead to good things
As an example, I'm a huge believer in TDD. This is mostly because its saved my bacon more than a few times. Though, I think even it has some limitations.
For example, during the initiation phase, I often like to prototype a couple of ideas first, before committing to an approach. I've had TDD purists complain that I'm doing it wrong, because I defer writing the tests (slightly) until after I choose the best approach.
I agree with some of the posters. I have seen quite a few methodologies and the frustrating thing I see, especially as it relates to agile, is that everybody believes it solves all software problems but they don't really understand what they are. Agile development is a method of development of software, not a method of everything. As an example, if I give you a cow and a tree and tell you to build a teepee, you end up short of a few things. How do I get cow hide? How do I get poles? How do I build the teepee? Do I have to fit it for one person? Yeah, that list could go on forever, but I think it makes the point. You have to do the basics. You have to do the analysis. You have to do the requirements gathering. You have to define testing, if you want to test? How? Unit testing only? Again, that list can go on forever.
In my experience the industry, and quite literally every job I have worked at in a decade, goes "we are doing agile application development, here is the customers old database it is 20 years old, you have to build a new modern database from it. You also have to modernize it, use all these new technologies and make it shiny. Oh and you can't talk to the customer." They then expect agile to just cover the development, not have any problems and make a perfect product without even finding out what the clients current needs are. It is ridiculous and it shows how the actual concepts of software development are dying to a culture of fads and not actually using the thing between your ears.
Last Visit: 5-Jul-20 20:56 Last Update: 5-Jul-20 20:56