Wow.. SCRUM is **horrible**...
-
Ah, yes ... and the DBA who has never coded an application and thinks everything has to be in 5th normal form regardless of how labor-intensive it might be to code against. "Thou shalt not have repeating groups" ... ever.
Jesus Christ, yes. It's funny, I'm the only real developer on a team of dba's, well, except one entry level guy. There are about 4 or 5 that do write code, some good, some bad, some just learning. It's nice that they appreciate it from point of view though. I get to code review them, too.
-
wizardzz wrote:
Where in my statements do I say there will be no sales people? Where do I even imply that?
It is implicit in the statement "everybody will have the ability to code". At best finding a good sales person that meets the reqs will be difficult. Finding many that meet it will be impossible.
wizardzz wrote:
Believe me, there are plenty of developers that want to move to sales.
I suspect we have different definitions of "plenty". And the fact that someone wants to do sales has nothing to do with whether they are good at it or not.
wizardzz wrote:
It's sh***y deadlines and bad promises that "must be kept at all costs" even if the cost is greater than that one sale, the man hours of developers to build product or feature is higher than the revenue generated to company minus sales commission.
That however is a management problem. Both in failing to manage the sales people and in agreeing to contracts that do not make money. Yet again another very important position that someone that slings code, no matter how well, is unlikely to be proficient at.
wizardzz wrote:
so what do they care about developers' long nights?
It is often the case that no one cares about that because it does not cost any more money in the short term at most places.
You seem to have a huge misunderstanding of this statement still:
jschell wrote:
"everybody will have the ability to code".
I do not mean code our product line, or even at a professional standard. I worked at a company where the CTO, a former professional trader, taught himself to code to understand the company and products better. He actually could code. His replacement, a former BA, could not. There are sales people where I currently work that can code as well. Saying some people can't code is bs; if you have any reasoning ability and any motivation, you can code. IT people ask me how to learn the basics of coding, I send them to codeacademy. The judge in an Apple lawsuit case taught himself enough about coding in order to understand the case. Mayor Bloomberg is even learning how to code. It doesn't take a certain type of person or mindset to code (though I don't advocate that, he doesn't run a software company and is a public servant). If someone wants to work in the software industry, I see no problem in expecting them to learn to code, even if it just helps them streamline their own processes. I work in the financial markets, I spent 2 weeks trading in our GUI to know what it felt to be a user with money riding on the performance. If I wrote software for any specific industry, I'd learn the industry. So if someone wants to do sales, accounting, planning, hr, in my industry, learn the basics. I'll quote an editorial in Forbes: Just the attempt to try to learn JavaScript, as Codeacademy starts students out with, is a useful and eye-opening exercise, no matter what you do in life. By familiarizing yourself with concepts such as variables, functions, loops and conditional statements you will begin to understand the vocabulary upon with the post-modern world is built. Learning to think in code will enable you to find the appropriate level of code to engage with to communicate better with others and make your own ideas more valuable to them.
-
You seem to have a huge misunderstanding of this statement still:
jschell wrote:
"everybody will have the ability to code".
I do not mean code our product line, or even at a professional standard. I worked at a company where the CTO, a former professional trader, taught himself to code to understand the company and products better. He actually could code. His replacement, a former BA, could not. There are sales people where I currently work that can code as well. Saying some people can't code is bs; if you have any reasoning ability and any motivation, you can code. IT people ask me how to learn the basics of coding, I send them to codeacademy. The judge in an Apple lawsuit case taught himself enough about coding in order to understand the case. Mayor Bloomberg is even learning how to code. It doesn't take a certain type of person or mindset to code (though I don't advocate that, he doesn't run a software company and is a public servant). If someone wants to work in the software industry, I see no problem in expecting them to learn to code, even if it just helps them streamline their own processes. I work in the financial markets, I spent 2 weeks trading in our GUI to know what it felt to be a user with money riding on the performance. If I wrote software for any specific industry, I'd learn the industry. So if someone wants to do sales, accounting, planning, hr, in my industry, learn the basics. I'll quote an editorial in Forbes: Just the attempt to try to learn JavaScript, as Codeacademy starts students out with, is a useful and eye-opening exercise, no matter what you do in life. By familiarizing yourself with concepts such as variables, functions, loops and conditional statements you will begin to understand the vocabulary upon with the post-modern world is built. Learning to think in code will enable you to find the appropriate level of code to engage with to communicate better with others and make your own ideas more valuable to them.
wizardzz wrote:
You seem to have a huge misunderstanding of this statement...I do not mean code our product line, or even at a professional standard.
You are wrong. I understood exactly what you were saying. From your very first response. My responses where based on that understanding. So given that you are under the false impression of my understanding perhaps you should re-read my responses with your new understanding.
wizardzz wrote:
I worked at a company where the CTO, a former professional trader, taught himself to code to understand the company and products better. He actually could code. His replacement, a former BA, could not.
Presumably you meant that the BA never wrote any code at all in the professional career. I suspect that is an unusual situation for a CTO in general. Certainly isn't common in the financial industry in general (yes I have experience in it.)
wizardzz wrote:
I work in the financial markets, I spent 2 weeks trading in our GUI to know what it felt to be a user with money riding on the performance.
Which does nothing but emphasis the point that I was making. That company was selling the product that you were using. They were not selling the underlying technology. Most developers will become proficient in the problem domain of the industry they work in either via training or experience. Just as a the marketing people will, the sales people will, the office manager(s) will and even the interns will. Because that is what the company sells. Software is only part of the company is selling even when the company does nothing but sell the product. Although many companies these days do not only sell a single product much less not selling any services.
-
wizardzz wrote:
You seem to have a huge misunderstanding of this statement...I do not mean code our product line, or even at a professional standard.
You are wrong. I understood exactly what you were saying. From your very first response. My responses where based on that understanding. So given that you are under the false impression of my understanding perhaps you should re-read my responses with your new understanding.
wizardzz wrote:
I worked at a company where the CTO, a former professional trader, taught himself to code to understand the company and products better. He actually could code. His replacement, a former BA, could not.
Presumably you meant that the BA never wrote any code at all in the professional career. I suspect that is an unusual situation for a CTO in general. Certainly isn't common in the financial industry in general (yes I have experience in it.)
wizardzz wrote:
I work in the financial markets, I spent 2 weeks trading in our GUI to know what it felt to be a user with money riding on the performance.
Which does nothing but emphasis the point that I was making. That company was selling the product that you were using. They were not selling the underlying technology. Most developers will become proficient in the problem domain of the industry they work in either via training or experience. Just as a the marketing people will, the sales people will, the office manager(s) will and even the interns will. Because that is what the company sells. Software is only part of the company is selling even when the company does nothing but sell the product. Although many companies these days do not only sell a single product much less not selling any services.
-
I've worked for a lot of different companies, but this company is the first one where they have been "official" / "gone overboard" on SCRUM. Why does anybody use this garbage methodology? It is HORRIBLE. Personally, I prefer a cool environment where everybody on the team works together, wants to make the product cool, you scratch my back, I'll scratch yours, etc. SCRUM just breeds a "me" mentality. Sorry Bob, I don't care about your issue until you open a defect and get it approved by a PM and get it inserted into a sprint. Yeah Jim, that feature sounds cool!! Write up a user story and submit it to the PM for approval and get it inserted into the current or future sprint. SCRUM is just anti-team work, anti-pride of ownership, anti-innovation. I used to want to make my product cool and get along with my fellow team members, but now with SCRUM, I have to be a dick and say "write it up and get the PM to approve it". Apperently though, SCRUM doesn't apply to my boss. He can come and randomly tell me to make changes when he is neither the PM or the PO. I'm also discouraged from doing anything above and beyond because everything requires a ton of paper work and 73 people to get involved. Use to be.. hey John, can you bust that out real quick? You mean change this bool to false? Sure, no problem!! Be done in a sec. Now its "submit all the proper paperwork and get the PM to approve it". Worst methodology ever. Thoughts?
I'm not sure what you're doing, but it ain't SCRUM. As others have commented, in SCRUM your boss has no say in what is or isn't in the sprint - but then again, if no-one who should have a say is coming to stand-ups, that's also not scrum. I really wanted to chime in and say that we have scrum working incredibly well in our organisation's IT, and in the team I am lucky enough to be a part of in particular. Our PMs are not the same people as our scrum masters; instead their job is more about translating our progress into the more Prince-y form that some other parts or the org require. Planning is a team effort, and getting something added in is as simple as writing a card with a few words (As a... I want... So that...), placing it on the wall below the waterline (yes, we have a physical wall, with physical cards), and having a brief team discussion in playing field after standup; from there it will be either brought into the current sprint (possibly pulling something else out to compensate), or put in the backlog for planning. Or, of it isn't a full story, just an action which may be part of an existing story, then that's even easier. Also, our team is incredibly collaborative: we physically sit together as much as possible, and are always, always chatting about details as we work together, and also taking on aspects of each-others's roles as needed. It really feels like our primary job is 'Agile team Member', each of us with certain stronger skills (eg developer, tester, analyst) rather than being a with agile team member a secondary part of what we do. Not sure this helps you any, but I just wanted to evangelise a bit that not only can scrum work, it can actually work incredibly well. I would hate to go back to waterfall, personally - and I was once a certified PMI PMP. (hated it; back to development only now).
-
I've worked for a lot of different companies, but this company is the first one where they have been "official" / "gone overboard" on SCRUM. Why does anybody use this garbage methodology? It is HORRIBLE. Personally, I prefer a cool environment where everybody on the team works together, wants to make the product cool, you scratch my back, I'll scratch yours, etc. SCRUM just breeds a "me" mentality. Sorry Bob, I don't care about your issue until you open a defect and get it approved by a PM and get it inserted into a sprint. Yeah Jim, that feature sounds cool!! Write up a user story and submit it to the PM for approval and get it inserted into the current or future sprint. SCRUM is just anti-team work, anti-pride of ownership, anti-innovation. I used to want to make my product cool and get along with my fellow team members, but now with SCRUM, I have to be a dick and say "write it up and get the PM to approve it". Apperently though, SCRUM doesn't apply to my boss. He can come and randomly tell me to make changes when he is neither the PM or the PO. I'm also discouraged from doing anything above and beyond because everything requires a ton of paper work and 73 people to get involved. Use to be.. hey John, can you bust that out real quick? You mean change this bool to false? Sure, no problem!! Be done in a sec. Now its "submit all the proper paperwork and get the PM to approve it". Worst methodology ever. Thoughts?
Having my first experience with SCRUM. Not overly impressed. Common sense codified at best where it actually does something good. One. SCRUM is lauded and promoted by management as a Holy Grail because it gives the appearance to the client of increased productivity by frequent release of usable software. But what about all the re-testing, all the design, all the riga-ma-role that goes into that one tiny incremental releases? Double or triple the overhead per delivered item. Frankly, I think it is just a way to make the hamsters (us) run faster even though I don't see any real decrease in time to stable, largely complete system. Two. It is very, very brittle. If anything is missing or weak, particularly if the client does not fully embrace the Product Owner duties, then it degrades quickly into the all too familiar daily endurance contest. If the team leader does not lead and only holds a daily stand up and while avoiding communication with the lower level hamsters the consequences are the same as a non-communicative leader regardless of project methodology. Oh, wait, there is no hierarchy in a SCRUM team. My bad, forgetting human nature naturally results in a flat organization. (Sarcasm intended). I could go on. But the point is that, in my observation, SCRUM is fine but only if executed perfectly. Otherwise it is just being used by management to mollify clients and makes us work faster and harder while being less productive and definitely less creative. I would say SCRUM is unfortunately usually implemented imperfectly and therefore creates situations opposite of the intentions for both the clients and the developers while making the usual management job of stomping on both fires at once all the more nauseating and difficult. Use carefully, use some of the modified Agile methods for larger projects. SCRUM is a White Elephant and not a Holy Grail in most cases.
-
I've worked for a lot of different companies, but this company is the first one where they have been "official" / "gone overboard" on SCRUM. Why does anybody use this garbage methodology? It is HORRIBLE. Personally, I prefer a cool environment where everybody on the team works together, wants to make the product cool, you scratch my back, I'll scratch yours, etc. SCRUM just breeds a "me" mentality. Sorry Bob, I don't care about your issue until you open a defect and get it approved by a PM and get it inserted into a sprint. Yeah Jim, that feature sounds cool!! Write up a user story and submit it to the PM for approval and get it inserted into the current or future sprint. SCRUM is just anti-team work, anti-pride of ownership, anti-innovation. I used to want to make my product cool and get along with my fellow team members, but now with SCRUM, I have to be a dick and say "write it up and get the PM to approve it". Apperently though, SCRUM doesn't apply to my boss. He can come and randomly tell me to make changes when he is neither the PM or the PO. I'm also discouraged from doing anything above and beyond because everything requires a ton of paper work and 73 people to get involved. Use to be.. hey John, can you bust that out real quick? You mean change this bool to false? Sure, no problem!! Be done in a sec. Now its "submit all the proper paperwork and get the PM to approve it". Worst methodology ever. Thoughts?
I think SCRUM works very good in some arrears. But not for writing of a "cool" product incorporating all features you can think about. SCRUM works very well for strictly regulated products or products with strict hardware limitations (medical system, defence contracts, embedded software and so on). I’m sure, you don’t want to read tons of tongue-tied regulations every time you have a bright idea, to make sure you new “cool” feature will be legal; won’t be life-threatening for patients in some weird cases; or its memory and processing time consumption is within specified boundaries. You want you PM to assign some BAs to do this job and report before the next sprint. Therefore, I think SCRUM is a great methodology in certain cases, but should not be used everywhere.
-
shiprat wrote:
the GUI, software components and exception handling (among other things) were invented at Xerox PARC
That's true, but in interviews I've read with Alan Kay, he endorses the approach. In fact Agile methodologies came from the Smalltalk community, which also invented GUIs, Refactoring, Test-Driven Development. As for C++, it's a bit of abomination really. No module architecture in 2013? No standard library for networking in 2013? Unfortunately, it remains the best way to write low-level code, but that shouldn't be counted as a sign of good design. Its lack of true support for dynamic dispatch is the reason we still have to regularly restart programs/systems when updating software.
..and C++ being what it is, all it takes is for somebody to implement dynamic dispatch, inline method cacheing, object prototyping and whatever else and use the much maligned C++ operator overloading to embed their extension snugly in a familiar syntax and ultimately submit the extension to one of C++'s gobnsmackingly and uniquely powerful open source libraries, Boost probably, and there you have it, a C++ as dynamic as Smalltalk or Javascript will ever be, and compiling to assembly language, therefore capable of verification and retargeting and probably smaller and faster as well. No wonder M$ have abandoned C#/.NET and returned to C++ for Windoze 8, which might yet be the best doze since win2k, despite being even! :D
-
..and C++ being what it is, all it takes is for somebody to implement dynamic dispatch, inline method cacheing, object prototyping and whatever else and use the much maligned C++ operator overloading to embed their extension snugly in a familiar syntax and ultimately submit the extension to one of C++'s gobnsmackingly and uniquely powerful open source libraries, Boost probably, and there you have it, a C++ as dynamic as Smalltalk or Javascript will ever be, and compiling to assembly language, therefore capable of verification and retargeting and probably smaller and faster as well. No wonder M$ have abandoned C#/.NET and returned to C++ for Windoze 8, which might yet be the best doze since win2k, despite being even! :D
shiprat wrote:
a C++ as dynamic as Smalltalk or Javascript will ever be
Well, I guess you could say that as V8 is implemented in C++ that's already been done, but I don't think that counts as a dynamic language.
-
It sounds like they're doing it badly wrong. They can only do it one way because the people selling SCRUM to the enterprise don't care how it is done. It's the responsibility of those making a living out of SCRUM to do it better. Whoever (a) wrote a book on SCRUM, (b) makes money providing SCRUM solutions, or (c) behaves or actually is a SCRUM-master. The people causing the problem are those who should be fixing it.
I think every methodology ever invented has good points, but is typically misapplied by people who understand it little. The methodology is then blamed rather than individuals who attempted to apply it without sufficient understanding. Remember the early days of OO?
-
Can you please tell me, since in all your replies you haven't, why it is a bad idea for everyone in a company that produces, sells, and supports software to spend 80 hours learning to code?
wizardzz wrote:
Can you please tell me, since in all your replies you haven't, why it is a bad idea for everyone in a company that produces, sells, and supports software to spend 80 hours learning to code?
It is a cost that provides no benefit. Repeating what I said from the first the number one thing that matters to a company is sales. If the company doesn't sell something it fails. Period. The same can not be said about software. It is in fact possible to make software that doesn't work and still make money. Probably not something that works long term but it does happen. So in terms of company success it would better if everyone spent 80 hours learning how to sell.
-
wizardzz wrote:
Can you please tell me, since in all your replies you haven't, why it is a bad idea for everyone in a company that produces, sells, and supports software to spend 80 hours learning to code?
It is a cost that provides no benefit. Repeating what I said from the first the number one thing that matters to a company is sales. If the company doesn't sell something it fails. Period. The same can not be said about software. It is in fact possible to make software that doesn't work and still make money. Probably not something that works long term but it does happen. So in terms of company success it would better if everyone spent 80 hours learning how to sell.
jschell wrote:
If the company doesn't sell something it fails.
Untrue. Many companies exist based on one single contract, a single major contract that does not require more than one salesman to make one sale. Often this is the CEO/owner anyways.
jschell wrote:
It is in fact possible to make software that doesn't work and still make money.
jschell wrote:
So in terms of company success it would better if everyone spent 80 hours learning how to sell.
I really hope you are being sarcastic as these are some of the most ridiculous statements I've read on this site.
-
Lol... so when your boss comes to you and tells you to make a random change, you tell him no? I tell other people no, don't really do that to my boss since he is my boss.
Our structure of our company is in such a manner that it prevents bosses from butting in. Bosses can't simply make demands as the team has the best knowledge of the impact of the demands. The bosses come to the team with a request. The team discusses this request and gives the boss a answer based on facts. Something like that in any case.
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
-
Scrum is great for weekly release cycles in e-business Zend or Rails shops that feel the need to tweak the user experience in step with the customer's attention span. Scrum is obsessive compulsive disorder for the enterprise. Luckily, scrum wasn't in vogue when packet switching was invented at DARPA or the World Wide Web was invented by TBL at CERN or the mouse pointer, Ethernet, the laser printer, the GUI, software components and exception handling (among other things) were invented at Xerox PARC and lucky scrum wasn't around when Linus Torvalds started work on Linux or Bjarne Stroustrup on on C++ or Brian Kernighan and Dennis Ritchie on UNIX and C or John McCarthy on LISP or Guido van Rossum on Python or Warren McCulloch and Walter Pitts on neural networks or Alan bleeding Turing on general computation or John von Neumann on the things wot do it because... ...NONE OF THESE THINGS WOULD HAVE BEEN DONE BY A SCRUM.
SCRUM is basically for client relations to keep clients in check. For innovations, Release Cycles do not work, but rather take away from the functionality of the task at hand. I don't think SCRUM would be effective if the company was not doing clients and should however be pushing its product to the market. SCRUM doesn't apply in that term.
-
shiprat wrote:
a C++ as dynamic as Smalltalk or Javascript will ever be
Well, I guess you could say that as V8 is implemented in C++ that's already been done, but I don't think that counts as a dynamic language.
name me something that isn't implemented in C/C++... I mean, yes ok, but the irony is that people are like, oh language X is so much more [adjective] than C, but you have to ask where did language X come from? maybe somebody wrote it in assembler or soldered it together out of logic chips, but the chances are higher that they wrote it in C or C++!