|
Eddy Vluggen wrote: 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"
|
|
|
|
|
80/20 rule.
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! 
|
|
|
|
|
Munchies_Matt wrote: 'Dont let lack of perfection hold you back' is my lesson from that!
An ex-employer used to say "perfection is the enemy of good enough" 
|
|
|
|
|
Let me add that to my list of favourite quotes!
|
|
|
|
|
Good enough begins to make money. Perfection just keeps costing money. This is a fundamental that separates businessmen from programmers.
I'm pretty sure I would not like to live in a world in which I would never be offended.
I am absolutely certain I don't want to live in a world in which you would never be offended.
Freedom doesn't mean the absence of things you don't like.
Dave
|
|
|
|
|
Mind you, those dealing with problems and failures, such as lawyers and doctors, make even more money than those who do good, such is the human condition.
|
|
|
|
|
DRHuff wrote: This is a fundamental that separates businessmen from programmers.
Almost doesn't count*
Depends upon who decides it good enough, doesn't it!
Something about per-ordained third-rate quality that goes against my grain.
Possibly because, although I love getting my check, it's never been about the money. The work you do is your art. Do you want to be proud of what you did or proud of what you got away with?
* (yeah, I know, except in horseshoes)
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
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.
|
|
|
|
|
|
Marc Clifton wrote: 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.
The very idea that I practice "agile" development cracks me up, we have stand ups and the PM used to try and put things into "sprints" and I still keep churning out applications like I have for the last 30 years. The tools have changed but the methodology is basically reiterative waterfall.
I have seen 1 enterprise project that was done with the whole "agile" culture implemented and it worked, even when outsourced to India. I was astonished! Then I found out they used my prototype done in WPF that took me 3 months as the basis of their Java web solution. Took 10 guys 18 months to build. Ok so there was lots of stuff I did not need to implement (eg. security) 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Standups get to me. The idea of "let's punish everyone by making them stand so they won't talk too long" sounds like something from elementary school, not how professionals act.
Just tell the professionals to limit their talk time, take longer discussions offline after the meeting, and have the scrummaster ride herd on the little doggies who forget what professional behavior is.
I refuse to stand in our "stand ups", and when asked why, I merely stated that I am an adult and a professional, and standing up like that is for children.
Then the whole idea of carving out daily meeting time whether it is needed or not, just seems so bureaucratic to me. I call this an article with my views on Agile, but some may call it a rant.
[^]
|
|
|
|
|
I used the word "prototype" once many years ago, and my manager freaked.
I meant and still believe in "iterating" (from a "good" knowledge / design base).
(He assumed prototype meant a "throwaway" at some point).
Part of iterating is "demonstrating" that everyone is on the same page.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Sander Rossel wrote: How do you want the address formatted?
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? 
|
|
|
|
|
Sander Rossel wrote: How agile are you?
Put it like this: if my username wasn't "OriginalGriff" it'd probably be "SessileGrog"
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: it'd probably be "SessileGrog"
That's a real Downer.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
In my experience, Agile works when
0. Customer know what s/he wants.
1. Product owner knows what cutsomer wants.
2. DEV knows how to change the Product owner to software.
3. QA tests what DEV delivers,
For any defects all teams Product, DEV and QA collaborate again.
4. Infinite loop 0-3 steps till the final product delivered.
It's really rare to find/build such team, due to skill, willingness, ability to pay more ...
Luckily I able to experience it since the customer is the owner of the Product, it's also participate in DEV and QA cycles.
How agile are you? I only work 30-40hr per week, but much effective with my teams.
In short Agile needs a team collaboration, from customer to product owner, DEV and QA. Otherwise you can't make it to be agile only because you have employees...
Logic will get you from A to B. Imagination will take you everywhere
- Albert Einstein.
|
|
|
|
|
If stakeholders understand how it works and are also agile I am willing to fill gaps o my own.
Of course I probably will miss something anyway, but I don't need to worry that someone will nag.
On the other hand if someone complains after sprint and stories were not specified well enough.
Then the only option is to push back next time.
|
|
|
|
|
Sander Rossel wrote: As an admin I want to see the address of a user on the user overview page.
You missed the zero'th question: Are you actually allowed to see that data under GDPR rules?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That's not really the programmers job to figure out
|
|
|
|
|
How about a "software engineer"?
You want to be treated like one?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I have the strong inclination to split some hairs here but I think it needs to be said. In your two scenarios you are talking about two very distinct things, neither of which have anything to do with AGILE. That happens to be the hair I am splitting. There is a highly important second word that the community has a nasty habit of leaving off when referring to "agile" and that it isn't "agile" it is "agile development". Like I said, a bit of hair splitting but important. Regardless of using agile, waterfall, or whatever; you have to have some basics. You have to have requirements (agile ends up using these to come up with the user stories, or a bunch of different names), waterfall uses this as requirements and etc. through other methodologies but they have to exist first.
Where this comes into your two scenarios is in the first, the questions that are being asked are being asked because the requirements are incomplete and unclear, in the second the requirements are not complete but this fact is being ignored. Agile is supposed to make it easier to develop and handle requirement changes but the community seems to accept, at least in my encounters, that agile is actually designed to allow us to not have all the requirements, and the ones we have not be complete, and we develop without them.
In practical experience what this leads to, at least in my experience, is the first method will ensure that the best application possible comes out in the alpha, beta, or whatever, with the minimal amount of time involved in basic things like layout and page views; the second method is going to result in a large amount of time spent in tedious things like altering a page layout a half an inch so one text box lines up with another, and repetitive views and things like this. I just wrapped a project, as an example, where a page had a registration form and nobody laid out the requirements and by the time we got close to the end, the one view, a simple registration form had been re-done seven or eight times with the irony of the me pulling up the original page and the final page and everybody realizing that the original and the final were exactly identical but we had redone it seven or eight times.
The first reminds me of someone understanding a real development process, be it agile or whatever, and the second being cowboy coding with no regard to thinking things out, wasting effort or repeating work.
|
|
|
|
|
|
It is interesting, I am actually okay either way. I usually tend to do cowboy coding if it is a smaller or a personal project but if it is slightly larger or if it is a work project I think having more details makes for a more successful project.
As software developers, we are used to having things change and shift and not really be locked down, but our customers tend not to be really comfortable with that, especially depending on the industry. I find most customers need a firm set of dates when things will be available, what they will cost and the level of effort things will take. You can't really give them that without having a significant amount of detail.
Quote: Exactly my current situation.
There's two things I can do: bitch about how nothing is clear and we're all wasting effort or trying to figure out what needs to be done and make the best of it.
I'm going for the latter, with the side note that I actually like working that way as talking to people and figuring out specs is a welcome change from programming
This is pretty much my thinking, for the most part, on not having things spelled out. I am pretty able to go with whatever is going on, but I really hate wasting my time and effort even though I get paid either way.
|
|
|
|
|
A "waterfall" project that is "chunked" small enough, becomes a series of "agile" projects ...
It's just a question of being able to prioritize.
(Just looked at a RFP from a muni govt with a "diagram" of their "plan" ... there should be a critical path; but it looks like a super nova ... Pass.)
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
