51–60 of 201 posts
For example original waterfall was kind of similar to agile methodology, there were re-estimations, milestones, prototyping... But I never heard anyone recently saying that our presumptions were wrong and we need to re-design and re-estimate.
Agile (scrum to be specific) in many companies is practically form of micromanagement. Number of companies are using 'agile' without automated tests and other necessary tools.
Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven. Our emotion comes into play when it comes to drive, motivation, hard work, creativity, and organization. Creating software requires motivation, creativity, organization, etc. Our emotion is behind software and we simply try to manage it with software developme…
Because it tries to fix human problems logically. Humans are not very logically creatures. We love to think we are, but most of us are very emotionally driven. But there is nothing stopping you from incorporating emotion into your logical models.
My hypothesis is that when you get engineering and management teams to try and manage out the creative aspect of most projects, things just go poorly.
In my experience, these methodologies are best described as cultish. The form of religion but not the power. Here's my methodology. * Figure out what the software does, what the business cares about, and what the users care about. * Figure out what it kinda sorta needs to be under the covers * Write prototypes of the technically gnarly bits. * Flesh out the prototype and start writing integration/functional tests for…
Too pragmatic. Where are the meetings?!
This made me think about the book "Shop class as soul craft". Cars use to be made by hand by skilled artisans. So did software. As with any process of production the move to change it in to a documented repeatable process complete with middle management has taken place.
http://www.joelonsoftware.com/articles/fog0000000069.html
I've been a web developer for 13 years. Following a specific methodology doesn't matter, as much as focusing on the important aspects of the project, which are the customers, and what difficult problem the product solves.
The funny thing is that even if a team does this, it is not guarantee of success. If the customer base is too small, or there are lots of competitors, even the best software will fail. Conversely, if the customer base is massive, and there are few competitors, even poor quality software can succeed. Luckily for the software industry, and not for consumers, most teams do not follow these guidelines with the net effect being a TON of poor quality software.
Obviously here, Stackoverflow, and various other programmer focused sites, it's common to focus only on the coding side of the equation. The reality is that the best software comes from the collaboration between customers, designers, programmers, testers, usability experts, and sales. When each group brings their strengths to the table and focus on a common goal and solution, everyone wins. However it's very rare, since often the programmers are seen as the builders, the designers as the painters, testers as a nice to have, usability as a fad, and sales as being helpless.
To clarify a bit: design != usability, functional != usable. A beautiful design does not mean usable, look at the very confusing swipe action based calculators on iPhone. Functional is an auditorium with 20+ projects, usable is having the specific video cable dongle.
This made me think about the book "Shop class as soul craft". Cars use to be made by hand by skilled artisans. So did software. As with any process of production the move to change it in to a documented repeatable process complete with middle management has taken place.
Then again, anything in software that can be made a "documented repeatable process" in a really deep way can simply be replaced with a well-designed piece of software. So software is all craftsmanship, because everything that doesn't actually need to be craft, we automate away pretty quickly.
Maybe they all don't "work" because people suck and get lazy? Things can be very pleasing when one works with developers use the planning tools and have a leader who never relents at keeping the team on track with a given methodology, all without being a bully of course. Of course it's rare in the real world, but it does happen.
"People suck and are lazy" is a known issue. It's been common knowledge for thousands of years now. So a methodology that doesn't work when practiced by sucky, lazy people is a methodology that doesn't work, full stop.
Just twisting an old joke: Good software development methodology is like a UFO - everybody has heard of it, nobody has seen it. Restricting a creative process into some pre-baked confines of thinking doesn't make a sense to me. Some rules are vital thought those should not get too much in the way. I think only organically growing your rules makes sense and you've got to accept there will be situations where you have…