4 ms·
The biggest determinant of success that I've seen is the skill of the programmers on the team. No McMethodology can make crappy programmers write good code. Pe
by api 16y ago
The biggest determinant of success that I've seen is the skill of the programmers on the team.
No McMethodology can make crappy programmers write good code. Period.
(However, really bad management can make good programmers write crappy code too...)
- cageface 16y agoExactly! Factors contributing to the success of a development project, in decreasing order of importance: 1. the skill of the team 2. the determination of the team to succeed 3. appropriate choice of technologies 4. process In my experience management agendas are much more likely to interfere with 1-4 than to help. There needs to be some kind of hippocratic oath for development managers and process enthusiasts. Everybody pays lip service to Fred Brooks but people somehow seem to keep forgetting his message.
- api 16y agoThey're forgetting it because they want to forget it. Businessmen want (for reasons that are somewhat rational) to commoditize everything, including labor. Programming labor has been stubbornly difficult to commoditize. Programmers differ in skill in very deep and complex ways, and can't just be swapped out like assembly line workers. This is immensely frustrating to the bean counters. Anything that comes along and promises to allow programmers to become commodities is going to catch on like wildfire. The desire is too strong from a management perspective. It doesn't matter how many times such efforts have failed in the past. What's old will become new again.
- ww520 16y agoExactly. Agile becomes popular because it gives managers wetdream to impose a factory-like process into software development.
- gamble 16y agoNot to mention that it appears to eliminate the long "measuring before you cut" thing at the start of new projects. Fingers on keyboards equals productivity!
- hello_moto 16y agoI met a ScrumMaster that sees things otherwise. The point of Agile (and Scrum) is to give responsibility back to the clients/managers: pick one -> time or money, you can't have both; we'll show you why from our user-stories, cards, task-boards, poker-game, scrum planning, etc.
- gaius 16y agoExactly, this is what "calibration" and "velocity" are about. But the elephant in the corner of the room is that skill still matters, you can't swap a good team for a bad one and get the same velocity. In fact it makes the management problem harder; now you don't just need "a hacker" but a whole team...
- joe_the_user 16y agoIndeed, Agile theory does make some nods to not commodifying the programmers labor and giving programmers autonomy. But when it's sold the bean counters, they filter for the parts that get them what they want.
- prototype56 16y agoWe have a lot of decent developers on our team. But management is still stuck in 90's where everything is done as huge framework building waterfall exercise. The word YAGNI doesnt mean anything to anyone here. So yea lot of skilled devs are writing useless frameworks when they could have producing real business value. So I would say the most important thing is the process once you have a decently skilled team.
- cageface 16y agoYeah that list only holds for successful projects. A broken process can quickly move to the top of the list of reasons for failure.
- deleted 16y ago[deleted]
- chromatic 16y agoYou left out #0, which is "Knowing what to build." I suppose discovering that is in the realm of #4. Hm.
- api 16y agoNo, discovering that is market research. I don't see how McMethodologies help there.
- chromatic 16y agoThat sounds like an assumption that everyone's in the business of selling software. I'm certainly not.
- WorkerBee 16y agoAre you in the business of writing software that never gets used? I have, and I hated it. Quick feedback means quickly finding out if you're building the right thing.
- chromatic 16y agoQuick feedback means quickly finding out if you're building the right thing. I agree. That's why I use a development process that encourages quick feedback. I don't consider that market research because I'm not out looking for customers to give me money in exchange for a DVD full of software. I'm sitting down with the person who hired me and demonstrating what I've done in the past week or two.
- jamesbritt 16y ago"No McMethodology can make crappy programmers write good code. Period." Can't a McMethodology help crappy programmers become less crappy (and eventually write better code)? Are there any methodologies that can help with this? Ideally, poor developers get replaced by better developers, but realistically this (for all sorts of reasons) doesn't always happen. So, if you're a project or team leader, what can you do to elevated the level of code from sub-optimum developers? Anything? Or maybe it's better to give them "fake" code to write so they stay busy and out of the way.
- gbhn 16y agoI don't think so, no. My experience is that mediocre and poor programmers take refuge in high-ceremony work environments like agile, where there is basically an infinite amount of non-productive "work" that can be engaged in, and no-one can criticize because they're following the process. I do think that poor developers can be taught to be better in a work environment, but it's a painful, slow process, and has to be started with an a keen devotion to the process on the part of the trainee, which if it were going to happen at all, would probably have already happened during college.
- chromatic 16y agoI have difficulty imagining an agile process worth following where standups don't reveal that people aren't doing worthwhile things, where retrospectives don't reveal that estimates have gone horribly wrong, and where pair programming doesn't reveal that some people shouldn't be writing software. What exactly do these high-ceremony agile projects practice?
- gaius 16y ago"Refactoring"