5 ms·

My dad has no background in IT at all. He once was appointed to lead the Operation division (everything including IT). He saw that the systems his bank used was

My dad has no background in IT at all. He once was appointed to lead the Operation division (everything including IT). He saw that the systems his bank used was buggy and spent a few days figuring out how the systems worked (flow of the systems, input, output, users, etc). He found the problems eventually. His solution to the CEO? The IT team should be discipline in almost every step they execute. Discipline in terms of execution, discipline in terms of documentation, discipline in terms of logging information, etc. Agile, SCRUM, or whatever new methodologies out there (including CMMI) directing engineers in the software industry specifically to be more discipline. Feel free to talk bad/negatives about CMMI, but the intention is to figure out what went wrong and how to not repeat the bad experience (describe in each level). In Agile, process is not equal bureaucracy. Process is equals discipline. - Eric Ries UNIX/Linux philosophies teaches software developer to be discipline. Google has a set of coding/commit rules, rigid structures regarding their source code (code review, etc) because they knew if things were not in certain order, chaos rises.

jrockway 16y ago
In Agile, process is not equal bureaucracy. Process is equals discipline. - Eric Ries This is false. Agile is total bureaucracy. From "no code without passing tests" to "pay $1 if you're late to the standup meeting", Agile is about everything but writing software that works. When I think back to "Agile" jobs I had, I can remember our team spending about 4 months writing 3 files worth of code that did basically nothing for the application as a whole. We did have a lot of meetings and tests, though. Conversely, when I think about code I've written on my own without any structure or rules, I have over 100 completed projects/libraries in a few years of hacking. And when I think about code I've written for non-Agile jobs, the amount is the same -- lots of reliable, finished projects. Agile is a way for the bad programmers to slow down the good programmers, so everyone can feel better about themselves. Avoid. UNIX/Linux philosophies teaches software developer to be discipline. How? When I write a Windows application, I have a full-screen Emacs with my code, a compile buffer for builds and tests, and a ghci (etc.) buffer. When I write a UNIX application, well, it's exactly the same.
- Silhouette 16y ago
  I think you're being rather unfair to Agile. The basic tenets per the Agile Manifesto are reasonable enough, and don't imply any of the silliness you described. Equally, the incremental style of development shared by all Agile processes has always been a better idea for most types of project than having some huge spec up-front and then not talking to anyone about it for six months. This was true long before anyone coined the term "agile" to describe the idea. Of course, if you choose to adopt something like XP as your process, then you go a lot further. Personally, I consider XP a rather silly idea, because its basic principle is flawed: just because doing something can be helpful, that does not imply that doing it religiously all the time is better. Likewise, the basic idea underlying Scrum is to have a prioritised list of stuff you need to get done, divided into practically sized chunks; to do a small number of them to make your next release that does more useful stuff than the last one; and then to repeat. Again, this is a sensible enough idea, and something that a lot of projects have done for much longer than the name "Scrum" has been around. It's only when you start adding on bucketloads of meetings and strict deadlines and people with silly job titles that it becomes rather comical. These problems with taking basically good ideas too far are not Agile's problem. They are just what you get when consultants smell book deals.
- hello_moto 16y ago
  > "Pay $1 if you're late to the standup meeting" If you're discipline enough with your time, you shouldn't worry about things like this. Life is not perfect, there will always be small things that might bother you but not other people. Take it easy, besides, like I said, if you're punctuate, why does it bother you much? maybe it is meant for your co-workers that have time-management issues. > "No code without passing tests" I've worked with smart people with big ego swinging their code like the best thing since slice of bread. I've worked with smart people who think they can solve everything by raw-talent. I've worked with smart people but not careful. In every situation, forcing TDD help to store "order". People out there seems to echo the same story. Now here's the thing, what should I do? should I accept your story and have blind-faith on the new guys? Thinking that they're smart and all that and no unit-test? Should I trust someone that say "I designed my code to be unit-testable, but I have no time to write unit-tests"? How many allegedly "good developers" out there that my company can afford to pay? Market also determines the price and right now the price of junior developers are quite high. And one more thing: I respect your skill for having over 100 projects over a few years of hacking. That's great. There should be more people like you, and less number of failed projects out there. What I'm trying to say is that the statistics (Standish Group) isn't on your side. TDD is a topic that would always caused a disagreement with a group of programmers who have "success stories" without TDD, open source projects where there are no deadline and have millions contributors (well, eventually the bug will be fixed right... eventually... someday).

jrockway 16y ago

In Agile, process is not equal bureaucracy. Process is equals discipline. - Eric Ries This is false. Agile is total bureaucracy. From "no code without passing tests" to "pay $1 if you're late to the standup meeting", Agile is about everything but writing software that works. When I think back to "Agile" jobs I had, I can remember our team spending about 4 months writing 3 files worth of code that did basically nothing for the application as a whole. We did have a lot of meetings and tests, though. Conversely, when I think about code I've written on my own without any structure or rules, I have over 100 completed projects/libraries in a few years of hacking. And when I think about code I've written for non-Agile jobs, the amount is the same -- lots of reliable, finished projects. Agile is a way for the bad programmers to slow down the good programmers, so everyone can feel better about themselves. Avoid. UNIX/Linux philosophies teaches software developer to be discipline. How? When I write a Windows application, I have a full-screen Emacs with my code, a compile buffer for builds and tests, and a ghci (etc.) buffer. When I write a UNIX application, well, it's exactly the same.

Silhouette 16y ago
I think you're being rather unfair to Agile. The basic tenets per the Agile Manifesto are reasonable enough, and don't imply any of the silliness you described. Equally, the incremental style of development shared by all Agile processes has always been a better idea for most types of project than having some huge spec up-front and then not talking to anyone about it for six months. This was true long before anyone coined the term "agile" to describe the idea. Of course, if you choose to adopt something like XP as your process, then you go a lot further. Personally, I consider XP a rather silly idea, because its basic principle is flawed: just because doing something can be helpful, that does not imply that doing it religiously all the time is better. Likewise, the basic idea underlying Scrum is to have a prioritised list of stuff you need to get done, divided into practically sized chunks; to do a small number of them to make your next release that does more useful stuff than the last one; and then to repeat. Again, this is a sensible enough idea, and something that a lot of projects have done for much longer than the name "Scrum" has been around. It's only when you start adding on bucketloads of meetings and strict deadlines and people with silly job titles that it becomes rather comical. These problems with taking basically good ideas too far are not Agile's problem. They are just what you get when consultants smell book deals.
hello_moto 16y ago
> "Pay $1 if you're late to the standup meeting" If you're discipline enough with your time, you shouldn't worry about things like this. Life is not perfect, there will always be small things that might bother you but not other people. Take it easy, besides, like I said, if you're punctuate, why does it bother you much? maybe it is meant for your co-workers that have time-management issues. > "No code without passing tests" I've worked with smart people with big ego swinging their code like the best thing since slice of bread. I've worked with smart people who think they can solve everything by raw-talent. I've worked with smart people but not careful. In every situation, forcing TDD help to store "order". People out there seems to echo the same story. Now here's the thing, what should I do? should I accept your story and have blind-faith on the new guys? Thinking that they're smart and all that and no unit-test? Should I trust someone that say "I designed my code to be unit-testable, but I have no time to write unit-tests"? How many allegedly "good developers" out there that my company can afford to pay? Market also determines the price and right now the price of junior developers are quite high. And one more thing: I respect your skill for having over 100 projects over a few years of hacking. That's great. There should be more people like you, and less number of failed projects out there. What I'm trying to say is that the statistics (Standish Group) isn't on your side. TDD is a topic that would always caused a disagreement with a group of programmers who have "success stories" without TDD, open source projects where there are no deadline and have millions contributors (well, eventually the bug will be fixed right... eventually... someday).