VBA Sucks???

Agile is neither good nor bad, much like waterfall or many other methodologies, what is good or bad is the implementation of it. I am not personally for or against agile it has its place in the right teams.

What does get annoying sometime (and i suspect this is what gets on Dilettantes nerves) is agile evangelists who proclaim it to be the second coming of software development which will solve all previous problems and magically produce better, faster, bug free software!

There are many places that have bad agile implementations either because they have tried to rigidly implement a (supposedly) flexible system, they implemented in a team which is not suited to it, or they just flat out don't understand it.

When i say implement it in a team that doesn't suit it, Agile works best when the majority of the team know a product (or at least the product domain) well, if you have a team that is basically learning the product at the same time as learning the methodology then they are setup to fail.

If you have a team that works on multiple products at the same time then agile does not fit well

If you have a development team of less than 4 people then agile does not fit well.

If you don't have proper business buy in agile does not work that well, as you have to change the way the product requirements are done.

Bits of agile can be appropriated by any developer and are good ideas such as breaking down your work into the smallest possible units i find be just good practice, but for the whole system to work and i have seen agile functioning well, you need the business to decided they are going to do it properly, and it needs to have big enough and experienced teams, and you need to be flexible and use the bits of agile that suit the way your business works and be prepared to change the bits that are not.

The bits of NSA's post I don't agree with aren't worth me flailing about, it's more like "Eh, I don't think that's right, but I haven't been in that scenario so maybe I'm naive".

What breaks it and makes people angry with it is a failure to recognize dogma. Statements like "It's not agile if you don't do daily standups" are dogma. They make as little sense as "VB .NET is not VB because it's a strongly-typed object-oriented language" or "You can't be a Baptist if you've had a divorce." There are valuable discussions to be had about project management, and they don't start with "Every process but this one is universally wrong."

The whole "Agile" movement isn't really anything new: it's a formal statement of "Whoa, a lot of successful projects share management characteristics, what if we glom all of those together?" The practices are things to consult if your opinion is more like, "I don't think it's possible to deliver software on time or on budget in any circumstances."

But if what you are saying is, "I deliver my software on-budget and on-schedule."? Well, I understand why you're not very interested in changing your methodology. It ain't broke. If someone tries to sell you on a new dream, feel free to ask them to print their certificates on softer paper so it feels better when you wipe yourself!

Agile as it's often professed spectacularly failed here... the nature of our clients and our business doesn't allow for it in its pure form. Oh sure it sounded great when it was proposed (by one guy who had become a "Certified Scrum Master") ... problems: 1) it was held up as the panacea of all things that are holy and good and everything we weren't at the time. 2) rather than gather support from the troops in the trenches, he did an end-run by convincing management, that it could be done and he was the "one" that could get it done. 3) He introduced a new all encompassing requirements & bug tracker system ... actually this is the one thing he did get right, we're still using it, and we're expanded it's capabilities by adding the Wiki documentation module to it. It's got built-in security too so you only see the projects you're assigned to, and clients can only see their project. 4) As part of that end-run, he (on his own) setup workflows that he thought we needed (I remember when it was all revealed, the questions being asked clearly showed it wasn't ready as doomed to fail) with out consulting any one else. 5) The guy was a complete tool... since he was "Certified Scrum Master" clearly he knew best, and that the rest of us were morons. And he's in charge of the Qa dept... crap, I have to work with this guy? 6) a couple random projects were selected for the pilot program... all those things NSA mentioned about teams that will cause agile to fail.... that's everything my team was. The project plan was bad from the get go, the PM had no backbone, wouldn't stand up to the client, for each cycle, I was given 3 days on site to get requirements - by a green BA too - followed by one day... ONE DAY for "sprint planning" ... and then it was code code code code code ... See something missing there? Design... there was no design. In short I was supposed to take the requirements, quickly add tech notes, then toss it over the wall to the offshore team... clearly agile in any shape was never going to work. Three years later the project is crap and we're still not sure it will ever make it to the finish line.

What we've done since (and ironically since the advocate left) is to take the bits of agile that works for us, that work for the clients, recombine it with waterfall DNA, run it through the blender, and have come up with something that allows for the long-term planning that we need, that our clients need, but is still flexible enough that it can scale up or down as needed. If I had to pick a name for it it would be "just in-time design" ... so far it seems to be working. The project I'm on now is using it. There are two in-house developers, two client developers, 4-5 off-shore developers, two in-house QA, one off-shore QA, one BA, and two delivery leads, one of which is also doubling as the architect & ring-master, keeping us all in line. Including all the pre-design & setup, the project has been rolling for about 18 months... development-wise, it's been running almost a year. So far we've hit all the marks & milestones on time. I've seen it ramp up in size, and I'm sure in about three months when we turn the corner and can see the finish line, it will start to scale down.

That's not to say the project has gone perfectly well the whole time... I have concern about the skill & quality of a couple of the off-shore resources, but that's for the post-mortem.

-tg

Two things stick out there to me:

One is that "finished projects" are worth way more than "certifications". That guy can be a 100% certified scrum master, but one has to ask: "Why was he looking for a job? Shouldn't a great project manager be something you poach from another company?" The only good reasons I can imagine for a fantastic manager to be on the market is, "My last company folded", or "I'm ready for a different company and you're offering me a compelling salary."

The other is it sounds like your shop learned the right lesson: your process is something you have to tinker with just like your code. If it's painful to do work because of a process, it's time to replace that process. Sometimes you goof up and pick a worse process to replace it. But when you settle on what works, it's a dream.

But that's agile management, not agile design. I guess we sort of ran off the tracks.

We're still tinkering with it... one gap that we are having tremendous problems with is the gap between what Sales sells and what the customization folks can actually deliver. Part of that process is there's supposed to be someone that is technical, that comes in and works with the client to determine what the gaps are between what the product does out of the box, and what they need it to do. That is the Gap Analysis. Then from that, the Scope of Work is drawn up... and that's where things start to go wrong... it usually goes something like this:
Ok, so we will deliver features A, B, C, and X, Y, And Z... and it's going to cost $3M to do it.
Hmm... that's too much, we don't want to spend that kind of money.
Ok, so if we drop A and Y... eliminate reports ... we can get the cost down to $2M.
and back and forth it goes until we're doing $3M worth of work for $1M ... the deal is signed, everyone shakes hand, the team is put together, the PM, the BA, the Dev, etc... THEN a project plan is created... of course that too goes through the rounds of making it shorter (Sales said it could be done) ... Everyone agrees to the project plan... and then travel/conf dates are set for meetings to start gathering requirements...

Part of the problem - and this was an issue company wide - is that for far too long each department worked in their own little silo... their own little world... sadly it was something that was kind of pushed from the top-down. Now there's been a complete overhaul at almost all levels. A lot of downsizing and a lot of deadwood has been cast off. And the processes and changes are still coming. Most are for the better, some are what we hope will be better (we're not sure it'll work, but the alternative is to continue what we were doing, whcih we know doesn't work).

So, yeah, the methods and policies take some tinkering. And I think that's what most people seem to not understand. There are no rules in agile, just as there's no rules in waterfall, or anything else. they are guidelines, recipies... there's no one single recipe for chocolate chip cookies... just like there is no one way to build software. So you take the best of the pieces you have, build your own Frankenstein method, and you keep replacing parts until you find the right combination that works. the other thing that I think people need to remember - shops should have more than one process and methodology to work from... you should have a "default" ... but there are times when you find that outlier that isn't going to quite work, it would be nice to have a Plan B to fall back on.

As for why the "Scrum Master" didn't stick around: it was management turn-over... he finally ran into someone else with even bigger ambitions and stopped listening to the agile advocate.


-tg

Quote:

---

Originally Posted by techgnome

There are no rules in agile, ....

---

Well, there are a few: "buy my book, hire me to lecture, buy the sashes and mugs and pins I sell, hire me back to consult."

But in general practice it seems to be broken-field running, often in circles. Right up until the project is canceled or worse yet started over again with another group of no-hopers and a new High Priest and Dogma.

Quote:

---

Originally Posted by techgnome

... just as there's no rules in waterfall, or anything else.

---

Well there isn't any such thing as "waterfall." This was an old term loosely applied in the 1970s by a few people. It was later taken up by people who chafed under the discipline of normal engineering practices. These anarchists later proved a fertile market for such patent medicine as "Agile."

Approaches often smeared as "waterfall" usually have a structure with phases like Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing. Sadly these were just as likely to be used to found medicine shows selling books, predesigned copyrighted forms to be filled out, lectures, consulting, etc.

But saying there are no rules is incorrect.


All of these of course are meant to guarantee the greatest success for ill-conceived projects with poorly defined requirements and low skilled and/or transient interchangable-cog labor. Since this is ridiculous the cost and rate of failure is fairly high.

Decision makers are addicted to this. They don't understand why software development should cost any more than their illegal immigrant gardeners, nannies, housekeepers, roofers, etc. There is no shortage of undereducated, unskilled, unexperienced, low-ball self professed "developers" out there to keep these false dreams alive.

Quote:

---

Originally Posted by dilettante

All of these of course are meant to guarantee the greatest success for ill-conceived projects with poorly defined requirements and low skilled and/or transient interchangable-cog labor. Since this is ridiculous the cost and rate of failure is fairly high.

Decision makers are addicted to this. They don't understand why software development should cost any more than their illegal immigrant gardeners, nannies, housekeepers, roofers, etc. There is no shortage of undereducated, unskilled, unexperienced, low-ball self professed "developers" out there to keep these false dreams alive.

---

So, what you mean is one of these, right?

• Aglie is the perfect methodology for VBA-to-VB6 projects, which are usually headed by someone who starts every thread with, "I'm not a programmer..." and is only just starting to realize they've fallen into a deep hole.
• Sweeping generalizations are a fallacy and should use enough hyperbole to make the sarcasm clear.

Well, this conversation sure isn't agile. More like ponderous, I'd say. This is chit-chat folks, not the dissertation forum.

Besides, I'm mad at you because your dogma chased my catma up a treema.

I like the pair programming aspect of agile. That's why I talk to myself.

Piiift! Paired programming... that's another idea that kind of came and went (under the guise of "Extreme Programming") ... here's how I saw (first hand) how paired programming worked:
One developer coding almost like mad, getting stuff done, occasionally maybe talking to the back seat driver, which then causes the first programmer to get off track, and the next thing you know you're trading fish stories. Meanwhile the FTE capacity is cut in half.
It's one of those things that sounds great at first, on paper, but then when you go to put it in practice, it doesn't work out so well.

-tg

I've done pair programming before, and I'm not really sure I like it.

For one, I couldn't be posting here if I was pairing. Ha ha. Maybe that's why bosses love it.

On the other hand, I'd get bored watching someone else code. Or extremely angry because they aren't doing it right. I'm often on a team where I'm the mentor in terms of practices, and I think it works best when the paired people are in agreement about the way code should be written.

But it /did/ work pretty well when I was paired with a newbie developer who was taking over the code I was fixing. She watched me make changes to the system, and along the way I got to show her where the extensibility points were and how to bend them the proper way. It worked way better than the usual, "Give her a ticket, then yell at her in code review because she had no clue how to update this codebase."

Look, I make a perfectly good quip, so don't go taking it all serious:mad::mad::mad:

(I'm a team of one, so pair programming can ONLY mean talking to myself).

Quote:

---

Originally Posted by techgnome

One developer coding almost like mad, getting stuff done, occasionally maybe talking to the back seat driver, which then causes the first programmer to get off track, and the next thing you know you're trading fish stories.

---

But...but...my programs ARE fish stories! Half the time, I don't know whether I'm writing code or just cod.

By the way, if you weren't a Certified Scrum Master, but were just somebody who talked about it all the time, would that make you a scrum wag?

Today's medicine show sells yesterday's miracle elixirs with new additives. Often they skip the middle man and just peddle the raw additives. These are called "patterns."

See Dependency Injection for an example of one of the more hilariously discredited ones.

Hoopers gotta hula I guess.

I'm sure there are gangs (they call themselves "teams") out there mixing plenty of such additives ("patterns") into their choice of raw elixirs ("methodologies").

Quote:

---

Originally Posted by techgnome

Piiift! Paired programming... that's another idea that kind of came and went (under the guise of "Extreme Programming") ... here's how I saw (first hand) how paired programming worked:
One developer coding almost like mad, getting stuff done, occasionally maybe talking to the back seat driver, which then causes the first programmer to get off track, and the next thing you know you're trading fish stories. Meanwhile the FTE capacity is cut in half.
It's one of those things that sounds great at first, on paper, but then when you go to put it in practice, it doesn't work out so well.

---

This was a scary trend.

Do you know where it came from? It was based on a random theory in early education that sadly got put into practice for a few years with disastrous results. It "paired" each dumb kid in class with a smart kid. Made them work together, take tests together, and share a grade.

One of my kids was forced through this. It was a mess, basically a lost year of elementary school. Entirely discredited now of course.

Quote:

---

But it /did/ work pretty well when I was paired with a newbie developer...

---

That sounds to me like it worked because you were basically doing intense mentoring rather than paired programming. It achieved the goal of the former (the newbie learned a lot about good programming and the system they were working on) but probably didn't achieve the goals of the latter (you were both more productive than you would have been individually).

I agree with the general gist here that paired programming is a stupid waste of time and I'm glad it's disappeared off the radar (I'd forgotten about it completely until it was mentioned in this thread).

I think some intense mentoring time can be hugely valuable for new/junior developers, though. I'm often hired as a consultant to come in on BI projects. The existing team members are pretty much never trained programmers - they're the guys who had some good excel skills who they then sent on a 3 day SSRS course and told them to produce a full BI suite by June. They're then left to their own devices with no support and no expertise to draw on. Alongside churning out a lot of the work myself, I'll make a point of sitting with them and mentoring them. You can watch them jump forward in ability, not because I'm a great teacher (I am of course... they call me mahatma... but that's an aside) but simply because there's simply no substitute for hands on mentoring through some real world problems. It's a very rewarding process for both parties.

Dilettante, we've heard all about what you wouldn't advocate. What would you advocate? And where do you get the impression that Dependency Injection is "discredited"? It a useful pattern which, like agile, is not a silver bullet and doesn't claim to be. It's simply one tool to solve a problem.

Quote:

---

Well, there are a few: "buy my book, hire me to lecture, buy the sashes and mugs and pins I sell, hire me back to consult."

But in general practice it seems to be broken-field running, often in circles. Right up until the project is canceled or worse yet started over again with another group of no-hopers and a new High Priest and Dogma.

---

Yeah that is not agile, that is just basically snake-oil salesmen by another name coming in selling a company a fake solution and calling it agile and surprise surprise the solution involves hiring that person on a very healthy salary!

Quote:

---

Piiift! Paired programming... that's another idea that kind of came and went (under the guise of "Extreme Programming")

---

Yeah i am not a fan of paired programming either, It tends to slow everything down and in the end it often becomes training by the back door.

Often you have senior developers sharing techniques with less experienced developers BUT really what this hides is you don't do any technical training and you don't share development techniques and best practices amongst your team which you should be doing anyway.

The only place I've ever seen Dependency Injection discredited when one or more is true:

• I'm on a VB forum.
• I'm interacting with someone that isn't experienced with DI who is in a situation that requires some experience to handle elegantly.
• I'm interacting with someone who doesn't know what they're talking about.
• I'm interacting with someone who has decided some set of practices is "best", and rejects anything else without analysis.

Dependency Injection is a pattern. A DI container is a data structure that helps you implement bootstrapping, a key concept in an application built around DI. "Poor Man's Injection" is an implementation style where you do not use a DI container to implement your Dependency Injection pattern.

I was not discrediting DI itself. I was relating that, in my experience, the DI containers I've used haven't provided significant value. I don't find code with a container much more maintainable than code without it. I'm inviting someone else to relate scenarios where it did work out for them. But in most of my circles, Poor Man's Injection prevails. Maybe I need new friends? It's always a possibility, in this market.

The most successful mountain climbers can be found at sea level with their limbs intact. They've climbed and descended many mountains, and that means they're likely to know things that will be helpful on any mountain you want to face. Some of them are missing limbs. Their failures make good lessons: you can still learn a lot from their mistakes. There's also a lot of corpses from failed descents. It's hard to learn lessons from them, but if you can figure out the mistakes they made you still get something.

The hermits who have established themselves at the top of one mountain only know how to climb one mountain, and have only done it once. To ask them how to climb their mountain, you have to know how to climb the mountain. They may not even know how to descend successfully. I'm not really sure why we decide they were very wise at all, or why we turn to them for advice.

Especially when we're surrounded by smarter people on the ground.

Quote:

---

The hermits who have established themselves at the top of one mountain only know how to climb one mountain, and have only done it once.

---

MAY have done it only once... it's possible that they have climbed several before... they got to the top of one, said "screw that crap, not doing that again, plus the view up here is quite nice" ... I've climbed a few... it's wearing on me... I plan to climb once more and be done with it. With luck it'll happen this year. I'll leap off the top of this one I'm on now, and start clawing my way up the next. The view up here, while nice is the same as it has been for a while, I need a new change in scenery.

-tg

That does seem to be what they tell themselves, yes. It could be that no metaphor is perfect.

But it felt a bit more profound than, "I'm going to keep up with what other people are doing successfully in the world and assume if what they're doing works, there's something to it. That seems wiser than asserting we got software development right in 1996, and no ideas afterwards could possibly improve upon it. It's all fluff and filler meant to trick you into believing that computing might have changed. There's no way any application could possibly require a different model than what my CRUD systems require."

This thread just goes to show: Sometimes when you grave dig a thread you awaken a zombie.

The conversation won't die even if MS discontinues VBA. Then the dialog will shift to, "Well, how long will it work for?" just as it did with VB6.

I don't know where it ends up. None of this is VBA's fault. But it doesn't work very well unless it's sitting on top of Windows. And MS seems to be moving its chips off of the Windows square. Part of me thinks it'd be unethical for them to completely discontinue VBA and/or Windows. The other part of me is pretty sure there's no contract anywhere that says they promise for VBA/Windows to be available in perpetuity. That's... a little scary.

If some other language pops up for Office Automation, my bet's on JS because it works on Mac OS, Linux, iOS, Android, and Windows. All of those are important platforms for MS, and I think it will be easier to integrate Office with JS than to reimplement an entire COM stack on several different native platforms. If you and your business rely heavily on Office automation, and you see MS implement a new language/stack, I think you should jump onto it as fast as you can.

That's still bleak, for the same reasons a lot of people can't upgrade to .NET from VB6. My guess is, as Windows becomes less relevant to MS, we'll get an "Enterprise Windows" that's eternally stable and increasingly expensive. That's going to hurt a lot of OEMs. I think MS is kind of bitter with them. I don't like what I see when I speculate on the Windows future. And that's really bad for VBA unless MS announces an iOS/Android/Web port pronto.

No fair bringing this discussion back to the topic.

Quote:

---

Originally Posted by Sitten Spynne

..And that's really bad for VBA unless MS announces an iOS/Android/Web port pronto.

---

Uhm,
Getting Started with VBA in Office for Mac

I'm not saying Droidsheet supports VBA, but it does use a dialect of Basic as a macro language.

Quote:

---

Spreadsheet functions are entered in the normal way and you can use a variety of mathematical functions, logical functions, selection functions, text functions, statistical functions and financial functions. The mathematical functions are ABS(), ACOS(), ACOSD(), ASIN(), ASIND(), ATAN(), ATAND(), COS(), COSD(), EXP(), EXP10(), LOG(), LOG10(), POW(), SIN(), SIND(), SQRT(), TAN() and TAND(). The logical functions are AND(), NOT() and OR(). The selection functions are IF(), HLOOKUP() and VLOOKUP(). The text functions are CONCATENATE(), LEFT(), LEN(), MID() and RIGHT(). The statistical functions are AVERAGE(), COUNT(), COUNTBLANK(), MAX(), MIN() and SUM(). Finally, the financial functions are FV() and RRI().

Although droidsheet was written for small android devices it still includes a powerful Macro Programming language that can be used for performing more complex calculations. This macro programming environment is based around a structured dialect of BASIC which includes ten data types (BOOLEAN, BYTE, SHORT, INTEGER, LONG, FLOAT, DOUBLE, COMPLEX, STRING and VARIANT) together with a variety of functions including mathematical, string manipulation, time and date, type checking, type conversion, and most importantly, some for manipulating spreadsheet cell values.

---

So such a thing isn't beyond the realm of possibility. But bizarro languages such as LUA, Python, and other Basic-inspired but self-professed "non-Basics" are more likely, and perhaps ultimately even JavaScript since even with all of its problems it seems to have become a default language on most platforms.

VBA on Mac's something I wasn't aware of. I'm curious if it'll pop up on iOS. I don't think the kind of place that'll abandon Windows is going to move to Mac Minis, it's more likely they'll pick up a flavor of iPad.

But that's interesting. I only did a quick search for "Office Automation iOS" when I was making the last post, I didn't think to check and see if Office for Mac had automation.