> Individuals and interactions over processes and tools
Trying to fit the people to the process is why software methodologies fail.
21–30 of 201 posts
> Individuals and interactions over processes and tools
Trying to fit the people to the process is why software methodologies fail.
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 the system.
* Ensure CI server is live, running integration/functional/unit tests and build documents on push.
* Primary work phase: code review, write tests, write code as you go along. Figure out if features are needed or not. Don't overdesign or underdesign.
* Document subsystems as they stabilize using comments and in-repo text files.
* End of project: everything is tested, documented, and working.
Rinse, repeat.
In my own anecdotal experience I would say the team matters way more than the methodology. I've been on teams that could have been (and were) repeatedly successful on projects that ranged widely from strict agile to strict waterfall. Every single time that team pumped out good quality software reasonably on time. I've also been on teams that were not successful no matter what methodology they used. The team just wasn…
One of the best features of good teams is that they are able to throw away unecessary rituals of their choosen methodologies.
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.
"It’s common now for me to get involved in a project that seems to have no adult supervision". But my bigger problem is that the youth of today seem to have a much bigger ego than the youth of yesterday.
"Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion". Recently working with an off shore team, they called their tech lead literally "God". And he was pontificating procedures and styles left and right without understanding the core of the software first. He stopped when the product start to have big performances problems. One of the ones that I liked the most was his prohibition to use class indexers in C#, backed up by an example in Java.
In contrast, I've been on SCRUMed and Agiled projects where the resulting overhead on those who can already get work done without SCRUM Master Jar Jar's constant interruptions reduces them to people who quit within a few months.
But hey, acqui-hires rock and I can't imagine a better way to drive the talent out of a stable Fortune 500 company in order to take a chance at a startup than by driving them $%!@ing crazy and reducing their productivity to jack diddly. Ah the cycle of life...
That said, I see the use of methodologies where the talent is both junior and mediocre. But the former is better addressed with good mentoring (ha ha just joking - mentoring is for wimps, am I right? am I right?) and the latter by not hiring the mediocre in the first place (which means HR needs to be disrupted stat and since they hold all the cards they won't be - cycle of life again).
3rd or possibly lower is the methodology used. The methodology's main purpose in my opinion is to align everyone's working style to milestones, it doesnt reveal anything about whether the project will succeed, only how we will approach it.
--Mike Tyson
How many people are over weight, who know that all you have to do is eat less, work out and then you will get in shape? It's that simple. Yet because of emotions, eating due to emotion, happy eating, sad eating, or poor self image many people don't get in shape. Likewise many students understand that all you have to do to get great grades is to avoid procrastinating, just start studying on time, study hard, study more, do most of the exercises in your text book, use multiple books and you are most likely to pass with high grades, yet lots of students put it off, poor will power, delayed gratification, it's more fun to goof off.
Same things apply to software, a lot of us know exactly what it takes to make good software, to spec it out, to plan a good architecture, to write good test units, to comment and document the code, to organize the process, to avoid over optimization, to avoid changing and adding lots of new features in the middle.
Yet, a lot of us don't do that, we start writing code before we even code before we spec out, because its exciting! Our emotions in play, we don't practice that delayed gratification of holding off and writing specs. We plan to throw away this prototype, but then somehow, it ends up being what everything is built on. We plan to refactor one day, but feature creep never allows for that. We know we ought to comment, but we understand the code now and don't, then 6 months later we are cussing and kicking the wall. Test units are boring, so we write as little of it as possible.
Until we take into account that programmers are humans, with emotions and different level of discipline, motivations and abilities our software development methodologies will keep to fail us for most projects.
Just my opinion.
Large corporations like to get everything down to a standard process (typically). A software development methodology lets them do exactly that; it promises a consistent process and (hopefully) quality.
In a way this works well - small firms innovate and come up with new methodologies which may at some point get to a tipping point where everybody wants a piece of the latest craze. Not everyone is in the business of questioning what works well or why - "if the competition is going Agile or setting up a DevOps team, then it must be good for us as well"