The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions. Or if you must, use the Back Room[^] - but enter at your own risk.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen. For those discussions where you wish to be a little more frank, use the Soapbox[^]
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
The software ideologies thread below got me thinking about the flexibility of some people and how well I work with them.
I just got out of a team who wouldn't want to start working on a user story until every little detail was crystal clear (but they still called it agile).
The story: As an admin I want to see the address of a user on the user overview page.
The questions: How do you want the address formatted? Where on the form do you want to see the address? Do you want address and house number in one field or in two separate fields? Do you want to see the address in that other page too?
That's a very short and simple story, but notice the amount of questions that HAD to be answered before they could put it in a sprint.
Personally, I'd put it in the sprint and I'd ask the story owner about the first three questions. That last question is out of scope, this is about the user overview page, not the other one too.
My current job is the exact opposite.
They want an entire application, possibly with about 10 third party tools, but they don't even know which ones yet (this has been going on for about a year).
And now I can start building... Figuring out the requirements as I go (which is probably about 50% of the job).
For Juun Software, my own business, I got a job "here's a fairly complicated Excel spreadsheet, we want that in an application. Good luck."
Alright, I'll build something, advice about certain subjects, and rebuild it if it's not what the customer wants after all.
Of course with everything clear up front you can make an estimate, you can build what is asked and you'll never have a dispute about if what you built is what they wanted.
With nothing clear it's pretty much impossible to estimate, things will take a lot more time, if your customer is an a**hole he'll give you a hard time for not building what he wanted or taking too long and without the right people these projects tend to fail miserably.
And then there's everything in between.
Personally, I like it when there's some work left for me to figure out. The more the better, like my current project.
Some people really can't deal with that uncertainty though (and when working with them I often find myself thinking "just start building already!").
It is often faster to simply add a setting for those than to go through the ladder and get opinions on how stuff should be formatted. "Just make it configurable" is a good answer to most of those questions, and a good way to teach them not to ask stuff they can answer themselves.
Sander Rossel wrote:
Of course with everything clear up front you can make an estimate, you can build what is asked and you'll never have a dispute about if what you built is what they wanted.
Even if the specs are 100% clear, that hardly means that the estimate is correct. I wouldn't wait for the specs to be at 100%; even when old-fashionably waterfalling that's a bit too much (and yes, I still do).
As long as your customer realizes that changes will also mean that the estimates change, you don't need to pour your specs into concrete. Code is very mallable in that respect, cement isn't.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
It is often faster to simply add a setting for those
Only if something somewhere is already configurable
On my current project everything is configurable, as it should be.
I'm not even halfway and it already paid itself back when the customer said "oh yeah, we were thinking we also want this and that" and I was like "you can add it yourself, it's all configurable"
Eddy Vluggen wrote:
Even if the specs are 100% clear, that hardly means that the estimate is correct.
It will be when you add the manager modifier of "developer's estimate x 2"
Deliver the bulk of the requirements, the must have, the basic functionality, and put the details, the 'nice to haves' till later. Dont let the second delay the first, thats the key for me.
And every plan can be changed, just make a start, make a decision and head in that direction. If it needs to change mid course, thats OK, at least progress is made.
Thats the way I design SW and run projects, and why I love the scientific method so much. Newtons laws arent perfect, but they are good enough to take man to the moon. For sat nav we need Einstains laws.
'Dont let lack of perfection hold you back' is my lesson from that!
The days are long gone when UI's would be actually storyboarded, though there are some great online tools -- I can't remember the one I used, but there's a plethora of them now. The idea being that all UI elements would be designed, the online storyboarding app that I used, you could click on controls that would actually do things, you could annotate the storyboard with questions, etc.
I found such tools really useful for discovering deficiencies in the UI and the UX. Really helpful to identify those things early.
To me, agile basically means "prototype." OK, there's a "process" part of Agile, but again, that's basically prototype iterations. At some point, the prototype ships, but the project never really started from a solid design.
So my ideal situation is where the UI, UX, data models, etc., are all designed before a single line of code is written. The design tool should then be able to generate UI, code, SQL, and models, leaving the programmer to deal with the real job of gluing it together, performance tweaks, testing, etc.
To me, Agile is just a BS game we play to compensate for the lack of planning but make it look like we know what we're doing. From my experience, anyone that actually has a functional Agile shop or defends Agile is actually doing good software development, and "Agile" is just the name they use because that's what the ignorant masses want to hear.
And the very first question is wrong. defining about the presentation before considering the data.
It only gets worse, "address and house number in separate fields." what? Now you know they are clueless (not all addresses follow this format).
I would stop them there and ask them one simple question: "when are the properly qualified people coming?" If they don;t know ask their boss because all they are doing is wasting your time with zero accomplishment to show for that.
There's not one iota of Agile in that, anybody who calls that so should find a new career asap.
Signature ready for installation. Please Reboot now.
I'm really not sure what you're going on about...
Sounds like a perfectly valid question (when considering that we only have Dutch addresses in our system and that's not going to change anytime soon).
Perhaps everybody considered the data, but you?
If any of you want to play with getting control back over your updates, this thread prompted an idea to create a bat file to possibly do the job. If you have any improvements to the bat, please post them, as I've never mastered all the arcanery behind that process.
Very cool, especially to implement this without having to write a complicated app, etc. That was basically what I was going to do, but as an app -- didn't even think about writing it as a batch file! There may be some other services that need to be disabled too, but those can be easily added to the bat file!
so you replace 1 program that runs continuously in the background with another.
But one of those causes considerable grief when your machine restarts without your permission. And technically, it is not a replace! They both keep running. But such is life in this case. Checked, and the command prompt is stuck at 0% usage if that is any consolation.
just curious, (I'm not on 10), what about stopping it and renaming the service .exe file?
Might be possible, but there are a couple other background processes that Windows runs that might trigger the file to be reimplemented. And I'm not knowledgeable about them.
Recently, I became older. Over the course of my life, this has been a disturbing trend. However, the alternative doesn't seem much more appealing. I'd be willing to "Benjamin Button" it for a few years, but that doesn't seem to be on the menu.
Now, don't get me wrong, I'm simply getting older. "I'm not old", he says, quickly concealing his gray hair.
I've noticed many older people ranting. It seems like it might be fun? So, I thought I'd experiment with it (in this post). I originally wanted to post this to my blog, but then realized I don't have one.
So, I'm posting it here instead. I'm hoping that the villagers will keep their pitchforks and Tiki torches in the shed. At the moment, I can't afford to pay a bridge troll its fare to pass.
So, anyhow, here goes...ranting powers activate...
I've been thinking a lot about software methodologies lately. Mostly, because there is no beer left in the fridge.
They always start out well-intentioned. "We keep falling behind our delivery schedules. Let's do something about that." Yeah!
Initially, much like a Mogwai, they start out all "cute and fuzzy". Then, someone feeds them after dark. Suddenly, they're trying to eat your face off.
OK, I digress, that might be some other critter. Honestly, I don't know much about Gremlins. I just know they're bad!
I think a better name might be software ideology. After the good intentions are long forgotten, the dogmatic elements become dominant.
"You can't do it that way." Why? Because, the methodology says its wrong.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
I continue to agree with absolutely every one of these goals. If anything, its almost an anti-methodology. I suspect, but cannot prove, the pain of those well-intentioned heroes.
However, it suffers the fate of most good intentions. It follows a life-cycle familiar to many of us.
Step 1: Save the World - Some people with good intentions, recognize a problem and try to fix it. "Let's write a few simple guidelines. That should help."
Step 2: Build a Better World - Inevitably, that damned imperfect "real" world refuses to cooperate. "It doesn't always work for us. Let's fuss with it. If we just add a few simple rules, it will be even better."
Step 3: Write a Book - People start to interpret or misinterpret those few simple rules. A couple more rules should add clarity. "These rules are a little unclear. Can someone maybe write a book on the topic?"
Step 4: Hire an Expert - Companies have difficulty consistently implementing the rules. A couple more rules are added to help. "We're having some trouble with those rules. Can we get one of the folks who wrote that book to help us with a lecture?"
Step 5: Get Certified - Companies recognize that people experience uneven success following the rules. A couple more rules are added to help. "Folks aren't consistently following the rules. Is there some certification they can get to make sure they understand?"
Step 6: Enforce The Rules - Companies recognize the results are still inconsistent. A couple more rules are added to help. "Folks are still inconsistently following the rules. Can we hire some management experts to help enforce them?"
Step 7: Build a Culture - Countless studies (with little peer review) conclude that this is THE WAY to develop software. "This is definitely the way to go, let's make it part of our corporate culture."
Step 8: Build a Religion - Evidence of a problem with the methodology seems to exist. "It didn't work for you? The methodology isn't wrong. You're just doing it wrong."
Step 9: Attend Seminars - – Fans of the methodology assemble. "Those dumb people still don't understand our methodology. Let's start a seminar so we can discuss it!"
Step 10: Recognize a Problem - The industry as a whole comes to realize the methodology is flawed, return to step 1. “Hey, this isn’t working. I heard about this new methodology. Let’s try it.”
I wish people would allow software methodologies to serve them instead of making it the other way around.
I wish people would recognize the wisdom in common clichés: all things in moderation, no solution fits all problems, etc.
If a methodology is working for a project, great! Use it. If its not, use a different methodology for a while.
Methodologies shouldn't be a suicide pact. Multiple methodologies can co-exist. Let's end the rule that new methodologies must kill off their predecessors. This isn't Thunderdome.
Ultimately, in the software industry, we're making sausages. It's sometimes an ugly business. However, if the product is of good quality and affordable, the process used to create it shouldn't matter too much.
Ranting wasn't as much fun as I hoped. I tried it. I don't think its the thing for me after all.
Ah well, there's beer in the fridge again...problem solved...ranting powers deactivate.
P.S. Apologies for originally posting this on Soap Box. After reading a few posts there, it seemed misplaced, so I moved it here. Long time author, but first new post on a forum, so hopefully I'm not too off base
The trouble with "methodologies" is that, sometimes, they fit the job at hand and the instigator/author gets all excited and writes a book about how well it all went and we should follow along and do the same thing, etc, ad infinitum blah, blah, blah.
The problem, of course, with this is that no 2 businesses are the same. No 2 groups of people are the same. And therein lies the rub. All processes, no matter how well orchestrated, are people driven. And people, for the most part, act like mindless cats and are impossible to herd in any meaningful way.
So, for me and me alone, the best approach has been to hire really smart people and let them get on with it. And they still all have personalities and characters and great ideas that tear down the "methodologies" and show them up for what they really are: a one size fits all problems that ends up being the problem.
Yeah, I like the notion of agile but I'm damned if I'll follow along slavishly. That is dumb.
Anyway, do what you want - people always do anyway.
ps I am also gaining age - it's been and is being a fun run.
Never let the bastards grind you down is the only pattern that really works for me.
Have a nice weekend, cats.
Keep your friends close. Keep Kill your enemies closer. The End
In my experience the problem is mostly just programmers who can't write decent software.
I've heard programmers say "software architecture isn't going to work for us, that's only nice in theory."
So no UI, business and data layers, no abstractions, no nothing.
No matter your software ideology, that's going to end bad (they were lucky that the software didn't change all that much).
Then I've seen software with a gazillion useless layers, just as bad.
Or software that took a non-DI library and used it as DI (the result was a very awkward method to instantiate objects when you need them, and no DI of course).
A completely wrong implementation of an ORM and the programmers who made the mess cursing the ORM (the problem really wasn't the ORM)...
Or a "core" library that every application depended on, but which changed almost daily.
These are programmers of all ages, not just the old farts.
No matter how clear or vague the business requirements are or how well your business structure is or how good the tools are you use, such software never ends well.
Maybe we should just learn to write software properly first.
After that we can worry about tools and methodologies.