Opinions needed.. (no, really! :))
-
Foothill wrote:
Nothing gets a programmer's motor running quite like a really sexy algorithm.
It's true. I too have fallen in love with my own code. :laugh: Other people's code is boring though. Meh. :-D
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
Narcissistic Programmer Disorder - a mental disorder in which a programmer has an inflated sense of their own code's importance, a deep need for admiration of their code and a lack of empathy for other programmer's code. But behind this mask of ultra-confidence lies a fragile self-esteem that's vulnerable to the slightest criticism. :)
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Agile or any other process enhancement really should be bounced up against a proven methodology such a Lean 6 Sigma. It could be called a process as well but I would rather refer to it as a methodology as in its concepts it seeks to examine the processes of accomplishing things. Among how it seeks to reach these goals it sets objectives of doing so in the shortest time frame, with the least effort, and with least amount of handling. So, if I would find that Agile or any other snazzy process came along and was being inflicted on a team harming its productivity, I'd be quick to slam it up against these principles and more than willing to be ready to jettison any component that was in violation. There are always new and better ideas to be learned and utilized, but common sense and its application once applied never get outdated. They continue to work and work well beyond the latest fad.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
As project lead / tech lead I assigned work, and when it was due (done), it was "unassigned"; and they were given the next task; and I managed any updates to completed work (integration and integration / system testing). This was possible because a proper design and partitioning of the problem and solution was done beforehand. "Agile" means "no planning" for most ... (And with "no plan" you can't really fail; so it's all good).
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Be very careful about changing anything right before a deadline. * If your team schedules 160 points, but can only deliver 40, the first thing you need to fix is to stop scheduling 160 points. 160 sounds suspiciously like 4 people x 40 hours a week. In case you haven't heard, people don't spend 8.000 hours a day coding. The go on vacation. They go to meetings. They get pulled off coding to fix tooling issues. They get pulled off to fix bugs. They yak about the Superbowl. But no matter what your points are, your record of delivery is the best estimate of your future capability. * If you have a critical delivery in a couple of short months (counting the Christmas holiday no less), it's time to 'fess up to senior management and your customers right now so they can mitigate the negative effects of the code being late. Abandoning your process right before a big deliverable is not a highway to success. Changing your process will make your schedule more uncertain, not less. * Writing tests may take as much time as developing the code; that's just the way it is. Test-first is a great way to wring out a design, too. Tests are not what the Agilists call "documentation". They are talking about 500 page Software Requirement Specifications and such. You complain that bugs are escaping module test and getting into demos. Abandoning your testing process is unlikely to make that better. Longer term, there may be some positive changes you can suggest to your team. Trust the team. If they want to do the right thing, they will want to improve on weaknesses in their process. * Make the team schedule larger refactorings as if they were story points. This will increase the visibility of what they are doing. If all they want to accomplish is refactoring, then maybe there's something wrong upstream, like poor design. Test-first is supposed to help wring out the design. If it's not working in this team, ask the team if it is valuable enough to retain. * Consider adding code reviews. Don't allow refactorings to be checked in if the team doesn't agree that it improved something. People hate working for a week and having it thrown away. Once this happens a few time, your team will become more focused on the need for any change they propose. Consider design reviews too, to make sure code needs refactoring before refactoring it. * Engage the team in a conversation about the bugs that escape module test. Honestly, my experience is that good module test finds most new bugs. Maybe some modules are not well teste
-
That was my recommendation, but that's off the table. These guys won't let go of Agile (I'm not against Agile, btw, but these guys are fanatics of [their interpretation of] Agile).. I tend to concentrate on getting finished products out fast with as few bugs as possible (while accepting that it's impossible to avoid 100% of bugs). Unit testing gets added for complex functionality but ignored for standard run-of-the-mill stuff.. has anyone seen any articles promoting rapid application develop (but without 3rd party frameworks) over Agile? I'm really looking for some evidence/white papers covering different ways of running the project - something that can possibly be enforced on the team, considering their poor performance so far.. One other issue, I'm an old-time coder (44 years old, started coding when I was 8), not a great people person.. (many of you may be surprised to hear that one! :laugh:) - these guys wear ties, have all the business spiel, great talkers and presenters.. makes it difficult to convince the guys higher up..
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
A few thoughts. You need to weaponize your knowledge. 1. Be aware of the difference between developer Agile and MBA Agile. It sounds like these folks are MBA style. Use that against them. 2. You say they dress and talk well. Throw out a few design pattern names. Hopefully they don't know them. That may cut them down to size and impresses management. 3. Make them fight among themselves. Tell one that their module must do this and talk to this other person's module thus. "You do not have a choice". Enforce that 4. Make a high level design and ask the/any programmer where their work fits into it. .... Youngster....
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
It is possible to have too many unit tests. Especially if they are testing lots of internal functions. Mostly you want to just test the external interfaces and if the internal functions are working properly the external ones will too. And of course as you've found out automated tests are great but can never replace an actual person using the product. You need testers, even if it's the CEO and receptionist. Agile is not against design, btw. Spend some time locking down those external interfaces and then DON'T CHANGE THEM. Combined with unit tests only on those external things, you can develop really quickly by relying on the mostly static tests to catch regressions. Stick to it. Even if you find out your external interface design could be better, unless it's really screwed up STICK with it. Fix everything in version 2. And exercise more control during story creation to keep people on track. If something works already, keep it and work on something that is broken.
-
There's a process to everything. Many people (developers) have no real process. THey just write code. Just writing code is terrible. The book attempts to explain a process that a real person(s) can use to create a product, not just code. Those of us, like yourself, who have a process that actually creates valuable products have no need of such a thing and consider the writers of such processes as snake oil salesmen (and many are).
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
raddevus wrote:
Many people (developers) have no real process. THey just write code.
I think that's nonsense. If there is any truth to it at all, then it applies mostly to those who are just beginning to develop. The rest of us have processes both formal and informal, structured and loosely structured, with which we get requirements, plan a strategy to develop the product, break it down into steps or sections, and then execute the plan. And these processes get stable, bug-free products created, tested and into production very well, thank you, as they have for all those years before Agile came along. Timelines are set based on what makes sense to the step(s) currently being executed, and not on some arbitrary and rigidly defined sprint blocks, without wasting time on daily stand-ups. Agile has some good ideas for some types of projects, especially those that can benefit from incremental releases. But some projects cannot be released in increments, some are actually impeded by Agile.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
raddevus wrote:
Many people (developers) have no real process. THey just write code.
I think that's nonsense. If there is any truth to it at all, then it applies mostly to those who are just beginning to develop. The rest of us have processes both formal and informal, structured and loosely structured, with which we get requirements, plan a strategy to develop the product, break it down into steps or sections, and then execute the plan. And these processes get stable, bug-free products created, tested and into production very well, thank you, as they have for all those years before Agile came along. Timelines are set based on what makes sense to the step(s) currently being executed, and not on some arbitrary and rigidly defined sprint blocks, without wasting time on daily stand-ups. Agile has some good ideas for some types of projects, especially those that can benefit from incremental releases. But some projects cannot be released in increments, some are actually impeded by Agile.
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
Agile is evil. It no longer values the coders and ends up in a blather fest. Let the non technical types have meetings and then put someone with tech knowledge in charge of assigning the work and coordinating the project. He should also have coding work. Assign someone you don't like to speak with the blatherskites.
Agile breeds black holes.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
It sounds like they aren't breaking problems up appropriately. It also sounds like the team is too large. We have a team size of only 2 developers, but we never take anything over 8 points and we are very cautious about those 8. We also rarely take over about 20 total points per sprint. If they only deliver 40 per sprint don't let them commit to more than that. Something else can always be pulled in later in the sprint if they get done early. Also, "Needs to be delivered by XX date" is almost always a bad way of thinking. It will cause a lot more defects and a lot more problems, and will usually cause the software to be delivered LATER than it could have been. Software is done when it's done. You may want to go back and say, "Well, we can't have the entire project by that date, but what is the minimum that will still be usable?" They will almost always say, "All of it," and then you get to say, "Well, then it will be YY date, at the very earliest, but we can give you (some subset of user stories) by XX date and deliver the rest later."
-
Mark_Wallace wrote:
That's because it demands that lowest priority be given to documentation!
That's a funny catch-22! :laugh:
It's a cop-out, really. There's no good way of fitting documentation into agile, so they just sweep it under the carpet. No technical writer worth his salt will document a function until it's been completed and signed off -- which only ever happens at the end of the sprint, so there's no time left for the guy to learn what it is/does and document it.
I wanna be a eunuchs developer! Pass me a bread knife!
-
It's a cop-out, really. There's no good way of fitting documentation into agile, so they just sweep it under the carpet. No technical writer worth his salt will document a function until it's been completed and signed off -- which only ever happens at the end of the sprint, so there's no time left for the guy to learn what it is/does and document it.
I wanna be a eunuchs developer! Pass me a bread knife!
Actually, it's explained as... ... The implementation is the documentation. It's a "forRealz" statement because they know that 99% of the time people create documentation then code and never update the documentation anyways so the documents never represent the implementation anyways. But, alas, 6 one way, half a dozen the other. People will argue both ways and that pays the consulting fees. :rolleyes:
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
What I've seen is programmers now who are terrified of writing code. They don't feel like they can write a simple for loop without a unit test (written first!) to show it works. Then you take all the unit-test passing code and plug it together and find it is all still buggy because unit tests don't catch everything and the most subtle bugs occur in integration (especially with anything event driven). My favorite sayings are "you don't ship tests" and "customers don't buy tests". What ultimately matters to the business is to ship working code. Absolutely write tests for subtle algorithms or pieces of code that have proven buggy. Writing tests for code that has to be refactored (for performance for instance) is great to prove that the behavior is unchanged. But it seems the modern programming culture puts all the emphasis on unit testing as if that is a panacea for delivering working systems. And don't forget that writing test suites for code that doesn't ship due to being un-needed or because it is delivered too late is completely wasted time. Maybe these guys haven't been on a project that failed due to being delivered late, and they have to learn the hard way.
-
Okay, so I'm working with a team that's (relatively) young and like to do things "the right way". This means Agile (naturally!), unit tests written up front, acceptance tests (Gherkin) too.. The problem is that very little gets delivered. In the last two week sprint, 160 points were promised but only 40 delivered. Same in the previous sprint. There's a bit of worry as they're working on a mission critical project that needs to be delivered in a couple of months. Personally, I think they're missing one major point mentioned in the Agile manifesto, in that.. > We are uncovering better ways of developing software by doing it and helping others do it. > Through this work we have come to value: > > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan > > That is, while there is value in the items on the right, we value the items on the left more. We're ending up with the situation that writing tests and refactoring is taking the bulk of the time. Things are being (IMO) over-tested and (also IMO) and there's an over-reliance on unit/acceptance testing to pick up all defects - real bugs are being missed and picked up at the point of actual system testing (or even worse, demo). On top of that, we've got developers going in changing working code simply because they think it should be done differently (in their opinion, better). And, if there's a complex way to write simple code you can bet this team will find it.. Has anyone else run into this? What was done to get the team focused on the important deliverables? I would like to understand how we can get away from delivering tests but very little product every two weeks.. :wtf:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
The bad news: You are probably toast. The good news: You know this now, not on the ship date. Agile is not a magic wand, you still need engineering skill. However, Agile processes are designed to expose problems. It worked. Given lots of test effort and still shipping bugs it sounds like a competence problem. How to deal with that is up to you and your organization. Sorry I can't be more specific as I have not hit that particular problem.
-
Hire some goons to have a talk with the worst offender every week?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.CDP1802 wrote:
Hire some goons to have a talk with the worst offender every week?
I think we've got that.. trouble is that the goons promote the guy every time :laugh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
-
There's a process to everything. Many people (developers) have no real process. THey just write code. Just writing code is terrible. The book attempts to explain a process that a real person(s) can use to create a product, not just code. Those of us, like yourself, who have a process that actually creates valuable products have no need of such a thing and consider the writers of such processes as snake oil salesmen (and many are).
My book, Launch Your Android App, is available at Amazon.com (only $2.99USD over 350 pages). Get my Android app on Google Play and F*orget All Your Passwords.
raddevus wrote:
Many people (developers) have no real process.
We got processes.. lots and lots and lots of processes, all documented, all heavily enforced.. that's part of the problem :laugh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
-
CDP1802 wrote:
Hire some goons to have a talk with the worst offender every week?
I think we've got that.. trouble is that the goons promote the guy every time :laugh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
What rank has he reached by now? Imperial commander of the order of the tweaked byte, fourth class?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns. -
Brent Jenkins wrote:
One other issue, I'm an old-time coder (44 years old, started coding when I was 8), not a great people person.. (many of you may be surprised to hear that one! :laugh: ) - these guys wear ties, have all the business spiel, great talkers and presenters.. makes it difficult to convince the guys higher up..
Then let your bosses decide wether they want to believe their talk or their results - and then they must act accordingly.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.Ha.. back in the office this morning and there's an email asking if we're all available to work weekends through to January.. :doh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
-
A few thoughts. You need to weaponize your knowledge. 1. Be aware of the difference between developer Agile and MBA Agile. It sounds like these folks are MBA style. Use that against them. 2. You say they dress and talk well. Throw out a few design pattern names. Hopefully they don't know them. That may cut them down to size and impresses management. 3. Make them fight among themselves. Tell one that their module must do this and talk to this other person's module thus. "You do not have a choice". Enforce that 4. Make a high level design and ask the/any programmer where their work fits into it. .... Youngster....
Michael Breeden wrote:
You need to weaponize your knowledge.
They're masters at this part of it all.. Had a meeting a few weeks back where I got a spiel about this process, that pattern, "re-hydrating entities".. basically re-loading the data from the database, but why say something in half a dozen understandable words when you can talk in paragraphs on a podium in front of clueless management? :laugh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
-
Ha.. back in the office this morning and there's an email asking if we're all available to work weekends through to January.. :doh:
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
I remember a meeting with a boss and his underlings where he was told that they were selling their product too cheap and that they were losing money on each item sold. His response: "Then we must sell more. Underlings, make that your top priority!" Sometimes I think that they don't put fools into a rubber cell with a tight jacket anymore. They just make them a manager somewhere.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a fucking golf cart.
"I don't know, extraterrestrial?" "You mean like from space?" "No, from Canada." If software development were a circus, we would all be the clowns.