What does everyone think of VBA and excel as far as i am concerned it si the most tempermental c**p i have ever seen and will probally drive me and my friends suicidal !!
so what u guys think of VBA?
Printable View
What does everyone think of VBA and excel as far as i am concerned it si the most tempermental c**p i have ever seen and will probally drive me and my friends suicidal !!
so what u guys think of VBA?
Worthless, just like Java Script
I vote crap, because it really is:mad: I only used it for a while, and when i did everything came up with Microsoft has performed an illegal operation forcing close.:mad:
in it's defence it has it's moments...
Wouldn't use it for anything remotely critical but i've found that populating a worksheet direct from a db which in turn creates a pie chart or something has won me more smiles from the common or garden user than the biggest projects i ever worked on
Considering it is the cause of 95% of Windows security problems, it is the suck! They have made every product they put out able to run VBA scripts with ability to run any command on your computer.
:mad:
Not to say VBA itself sucks, but if MS would have implemented it for what is shouled be used for like automating tasks locally by Admins, then it would be fine.
You can't compare VBA to JS. JS is highly usefull in web developement. I use it ALL the time for field validation.Quote:
Originally posted by kasracer
Worthless, just like Java Script
VBA is a pain in the arse to work with.
Over 90% of all java script created on/for the web does not validate (i.e. was not coded properly) so it usually doesn't even work correctly on other browsers besides IE.Quote:
Originally posted by Arc
You can't compare VBA to JS. JS is highly usefull in web developement. I use it ALL the time for field validation.
Therefore, I usually have it disabled, or if it's enabled it usually doesn't work.
It's worthless
You can't say that a coding language is worthless simply because developers don't use it properly. :rolleyes:
Yes I can and I just did :DQuote:
Originally posted by Pc_Madness
You can't say that a coding language is worthless simply because developers don't use it properly. :rolleyes:
VBA sucks a LOT of @$$.
VBA in Access, though, is the mother of all things unholy and putrid. This disgusting union should be banned. It is bollocks.
I have a big book on Javascript and even after reading it in its entirity and gaining a sound understanding of it I still found it a struggle to use in my web pages.Quote:
Originally posted by kasracer
Over 90% of all java script created on/for the web does not validate (i.e. was not coded properly) so it usually doesn't even work correctly on other browsers besides IE.
Therefore, I usually have it disabled, or if it's enabled it usually doesn't work.
It's worthless
Javascript would be a great language if it was fully supported by all web browsers. To garuntee a script that will work in the vast majority of web browsers you need to write reems of code, test it in a whole host of browsers old and new and then do your best to minimize the huge bandwidth which will be used for downloading it. Then you realise that for all your efforts most of your visitors have disabled Javascipt becuase it is used in those annoying popup Windows.
It is usually safe to assume that the majority of your users will support the Javascript 1.1 specification making it the reality that Javascript is only good for a bit of client side field validation.
This is probably why websites now rely mainly on server side technologies such as PHP and ASP.
I wont use it outside of work, but at work, it cut my job time doing retarded reports from 4 hours to 10 minutes.
I like vba, it adds a lot of functionality to the microsoft office applications
i secone that thought,Quote:
Originally posted by numtel
I like vba, it adds a lot of functionality to the microsoft office applications
not only to microsoft apps but others
like Great Planes..
o wait microsoft bought them too recently
vba is good for what it was designed for
Well, we write web apps, so when potential customers ask what browsers will it work with, we say IE 5+. If they have a problem with that, we tell them to move on.Quote:
Originally posted by visualAd
Javascript would be a great language if it was fully supported by all web browsers. To garuntee a script that will work in the vast majority of web browsers you need to write reems of code, test it in a whole host of browsers old and new and then do your best to minimize the huge bandwidth which will be used for downloading it. Then you realise that for all your efforts most of your visitors have disabled Javascipt becuase it is used in those annoying popup Windows.
It makes the javascripting just a little less painful.
That's a little suicidal. Its like opening up a shop and saying to your customers you can't go inside unless you have a blue car.Quote:
Originally posted by nemaroller
Well, we write web apps, so when potential customers ask what browsers will it work with, we say IE 5+. If they have a problem with that, we tell them to move on.
It makes the javascripting just a little less painful.
More like you must be at least 5' 9" to ride this train.Quote:
Originally posted by visualAd
That's a little suicidal. Its like opening up a shop and saying to your customers you can't go inside unless you have a blue car.
Remarkably, our clients don't seem to mind. And these are large well-known household-name clients.
For the most part, I think because IE5+ has the best support for client-side processing, and thereby reduces the traffic on the network, the clients are all for it.
I don't know how many of them realize MS stopped supporting IE for unix... but hey, not my problem.
VBA is a decent tool for the purpose it was created for - simple Office automation tasks... You can't compare it to other programming languages just like that... If anything Javascript is closest to be compared with VBscript and VBA and it is c**p compare to VBA IMHO - with anonymous functions and all.
This topic keeps coming and going with many "predicting" VBA being dead:
http://analystcave.com/vba-dead-whats-future-vba/
http://dailydoseofexcel.com/archives...a-development/
http://www.crazyontap.com/topic.php?TopicId=66147
I am curious... if MS removed VBA what would you expect it to be replaced with? Having to install Visual Studio and running scripts in VB/C#.NET?
On the other hand no one can't argue that VBA needs some enhancing/upgrade... the VBA Project environment smells of the 90's.
You resurrected a 13 year old thread. That's a solid chit-chat move.
It's kind of interesting to read what people were saying about JS that far back. It's become so much better adopted and used, by now, but it was not back then.
You don't need VS to write .NET and you never did. There was some talk of replacing VBA with .NET a few years back (like maybe 10, perhaps), but not so much anymore.
I fully expect to receive an email about a reply to a 30 year old VBForums thread down the road, and hope to see you there to reflect how technology changed. It is quite possible that in 30 years, all 'coding' will be done by the deep brain cloud, which of course, won't code in any of this nonsense people created. I just hope to reach retirement before it replaces us all.Quote:
Originally Posted by Shaggy Hiker
Almost 40 years and counting. Fortunately, I liked programming for the programming, so didn't really matter what the forecasters said. The work and being paid for it is mostly a bonus.Quote:
July 1977
Players, my Dad, and a professional programmer who worked at the large manufacturing firm he was employed by at the time.
Dad: My son is starting to learn about computers and wants to be a programmer.
Programmer: That's a dead end. They are developing software that will soon have the users specify the requirements and the program will be automatically created and run without the need for programmers.
I think it's worth noting that, like "Is VB6 still OK?" this is a question that's going to keep coming up.
I don't think the VBA language itself is "bad", but it lacks a few things that make JavaScript and other, newer, dynamically-typed languages more convenient. Part of the problem with VBA is it isn't dynamically typed, it's a late bound statically typed language. That makes creating classes an affair that requires more up-front work, like in big brother VB. And it has to interface with COM's memory management, which requires a decent bit of thought to get right.
But the average automation project starts its life in prototyping, where you least want to be doing up-front thought. You want to get a lot of things done quickly, then step back and formalize the prototype code if it's not a throwaway. In JavaScript, you're free to create some random object and add properties/methods to it as you see fit at runtime, because 'object' is synonymous with 'dictionary'. In VB, you can't add properties to things on the fly, you have to go update the type definition.
What I mean is VBA is better at rapid prototyping than VB, but it's still not very good at it compared to several other choices that exist today. When it was developed, maybe JS was around, but in that context I can understand sticking with VBA over JS. In today's world, it's insane. It feels like MS was once very good at leaping ahead of the curve and defining what the future would be. Now, saddled with the burden of compatibility promises, they can't even keep up while strapped to a rocket. They're only allowed to do something "new" and "exciting" if it doesn't rock the boat. The boat capsized and sank in about 2008.
I think that makes JS a strong answer to, 'What could replace VB?'. It can play the part of Perl and let you write nightmare constructs when you aren't really sure what you should be doing. And when you're ready to apply some discipline, it has a complex enough type system to facilitate good practices. If you haven't been asleep, you might've noticed Office works on the Web, Mac OS, iOS, and Android now. None of those platforms support VBA, but all of them support JS. I'd be willing to bet in the next few years MS is going to unveil a JS automation API for Office. They've already dabbled with HTML/JS as an application platform on the WPF side. That tells you they've at least prototyped it.
Plus also, tons of devs understand JS. A much smaller subset understand VBA, and a big subset doesn't want to touch anything like VB out of superstition.
The hangup is they somehow have to recreate the COM API in a way that's both sensible to access from JS and familiar enough that VBA developers won't result. They've got a slight advantage in there's still not a really good competitor to Office for angry mobs to jump to. What's more likely to happen is the enterprise deciding "Well we'll just run Office XP forever and never upgrade." That's risky, and unsustainable.
It feels to me the conversation in these threads usually involves a lot of, "Well I'd lose my job if that happened so I'm angry you'd suggest it." I don't like the thought of losing my job either. That's why I dip my hands into other things every now and then, just in case I can save myself by changing my title.
I'd normally say, "I don't want VBA to go away", but I actually do. The automation API is a mess, and COM feels very rickety from the viewpoint of a developer who didn't grow up using it. We'll all be a lot better off with a new iteration.
AWESOME! I was going to mention that resurrecting an old thread might cause a lost soul to revisit. This one brought back Nemaroller!!
Heaven forfend!!Quote:
Originally Posted by Sitten Spynne
JS is a nightmare language compared to VBA. It gives you plenty of rope with which to hang yourself, and even ties the knots for you. All that versatility means that you are only really productive if you are really disciplined when writing, which is not what VBA was intended to require.
Having used LibreOffice a bit, I'm not sure that I'd agree with that statement. Apache OpenOffice is also a contender, though due to the oddities of Open Source licensing, OpenOffice can feed LibreOffice, but not vice versa.Quote:
They've got a slight advantage in there's still not a really good competitor to Office for angry mobs to jump to. What's more likely to happen is the enterprise deciding "Well we'll just run Office XP forever and never upgrade." That's risky, and unsustainable.
I guess I shouldn't be surprised to see that people still confuse WinRT and WPF at this late date.
WPF is not used at all in Metro/WinRT. There are two different though similar markup languages that are both being called XAML just to lure in the gullible. However it doesn't apply to Metro crapplets made using HTML5+JScript where HTML is the UI markup language.
This internet thing'll never catch on
Climate deniers! Oh well.
In the meantime Anders is still at it, trying to put his stank all over JavaScript by front-ending it with a private macro language:
TypeScript 1.8 Hits Beta
Maybe that'll be used to try again in the wake of the massive fail known as VSTA/VSTO?
Actually, that's an evolutionary move. Javascript, as it stands, pretty much sucks rocks. The purpose of a language should be to assist in taking a concept and turning it into working code. A language can help with that or it can hinder. JS is more the latter than the former, and it doesn't need to be that way. The prototyping concept is fine, the ease with which you can totally mess up is stupid. If I have an object with a member called Species, and one time I type it species...yeah, that's totally legal, but 99.9% of the time it is also a mistake. Any reasonable IDE could point out that it is probably a mistake, while allowing it to happen if it isn't, but that's not the JS way. Instead, if it is legal then it's legal and that's all there is to it. Of course, that particular complaint is largely about the IDE, but that's all TypeScript is anyways.
TypeScript emits plain JS that is exactly the same as what you could write yourself with a set of standards and a bit of discipline. In that way, it is more like a high level language over machine code: You could have written all the same stuff in ASM, but you didn't, largely because ASM doesn't help you at all, but just makes it harder to write good code (and machine language is even worse in that regard).
I expect that the people who write in JS will eventually become like the people who write in ASM: Insufferable, yet less productive.
What i like about your posts Sitten, is you never post a sentence if a few paragraphs will do the same job :) !Quote:
I think it's worth noting that, like "Is VB6 still OK?" this is a question that's going to keep coming up.
..........
..........
Whats that then?Quote:
This internet thing'll never catch on
I could say a lot about why I like JS, and if people were writing code more like the Agile/testable movement advocates (which is really their contribution, not the process) then VB starts to feel like its type safety gets in the way.
It's kind of moot, though. I think what Office needs more than a new language is a new automation API. The boilerplate .NET for Excel interop reminds me of the boilerplate for a "Hello World" app in C, it's just as impenetrable for a newbie, and it's just as catastrophic if you get a tiny bit of it wrong. I don't really care which language they choose, but I think the reason they're so reliant on late binding is because COM demands it.
VBA doesn't suck any more or less than JS. In the hands of unskilled developers, every language is some degree of terrible. But the Office automation API almost demands a usage pattern that's more Goofus than Gallant. If it's hard to do the right thing when you have skill and discipline, expecting newbies (especially "not a programmer" newbies) to work with it is cruel.
Why do you say that type safety gets in the way of Agile? I don't think I've ever heard that assertion before.
Attachment 135099
Agile software development
Attachment 135101
Another look at Agile
Man, you're down on that, too?
Well, it is a bit of a fad, but we don't have an excellent solution, so why not try a fad?
"Methodologies" begin with people trying to solve some problems in software development. Sadly these often turn into medicine shows where there are usually pricey books and consulting tours where somebody takes the prior work, distorts it, and then makes outlandish promises.
Then this is taken by shops, comprehended at some minimal level, and applied as a religion. The motivation is usually one of desperation to create silk purses out of sow's ear teams.
The result is pretty much what you'd expect.
There is no substitute for good requirements gathering, deep programming background, reasonable testing practices, and lightweight project management. No imperfectly understood ritual practices can make up for the lack of these things.
Sadly these days any low-ball coder who can get "Hello World" to work seems to get hired, and then in desperation people sell their souls to these traveling shows.
See a confession:
Software Engineering: An Idea Whose Time Has Come and Gone? (pdf)
By the time WE hear about them, they are ALL medicine shows. Somebody finds something that works for them and they use that. When they decide that both it is THE solution, and they are interested in spreading the gospel, that's when the rest of us hear about it. Up until that point, every single coder has a methodology (good or bad). It takes some proselytizing to change it from a methodology to a Methodology, so all we see are the medicine show stage.
Still, there are some aspects of agile that do make sense to me. I have never found a case where a design of more than trivial complexity couldn't be improved upon, and couldn't be improved upon by input from knowledgeable others. So, I would say that while agile is still an example of groping in the dark, it's at least groping in the right direction.
Ahh, but "aspects of Agile" are not Agile and probably not unique to Agile anyway. For example everyone agrees that breathing is a good thing, the fact that Agile doesn't (yet anyway) rule out continuing to breathe is very little to its credit.
However Agile is similar to the newer medicine show called "DevOps." Similar in that dumping more unskilled voices into the pot will somehow magically create success.
You can have great success combining the two as "Agile DevOps." What does this mean?
It is a social engineering tactic that involves cosying up to the users and the operators ("admins" - oh I can hardly keep a straight face) to get buy-in. It does mean some wasted time implementing crackpot notions and making them take part in testing so they can see what lunacy they are so you can rip them back out and reach successful results. The trick is to implement and discredit as many of their wacky ideas as early as possible, after which they're just along for the ride and mostly sit quietly.
You get information you need out of the users about actual requirements that they are too illiterate to express in writing, and you get resources out of the uneducated "certificated" box jockeys.
Be sure to hand out badges, pizza parties, etc. all around and issue status reports praising their roles and contributions to the effort.
Smarmy? You bet. This why some burn out and others take to drink or vanish into the woods and start eating mushrooms though a few thrive on it and eventually run for political office.
It's a bit philosophical.Quote:
Originally Posted by FunkyDexter
While I'm writing C#, I'm constantly thinking about types, even when my code units are small. This line of code can go a lot of different ways based on the types involved:
Are a and b integers? What if one is a double? What if one's a double and the other's a single? Do I want an integer result? Type inference is a convenience, but in "int Foo()" I have to guarantee by the end of the function that c is at least implicitly castable to an int.Code:var c = a / b
That sounds not so bad, but only because this is a trivial example. This little nightmare's been bothering me lately in a SQLite library I use:
It returns the first column of the first row of the resultset from the query. Good so far. But that can be a double, long, string, DateTime, or probably some other value I haven't encountered yet. Obviously I wrote the query when I call it, so I have some clue of what it is. But I never expect it to be a long, and always get burned by the cast.Code:Function ExecuteScalar(query As String) As Object
In JS, I'd expect "a number". And I'd treat it like "a number". And if it gets a string back, it's going to bomb at runtime just like it does in C#. Except if for some crazy reason I go from "250 rows is a lot" to "6 billion rows isn't much", I don't get blindsided like I would in .NET when an API chooses Int32 where Int64 should've been used (like array length).
It's a very strange situation if all you've ever done is static typing because while you're in that state, it feels like you're catching so many errors. But all I notice now after writing some JS and Python is how often a C# "Unable to cast..." error represents some situation that would never be an actual runtime error in my code. And how many other times it's caused by getting caught up in vagaries of <TGeneric, TType, TParameters> and having to please some arcane god. It's not the kind of thing I can demonstrate in a trivial example, it's more like "At the end of the day, I feel like I waste 2-3 minutes out of every hour dealing with type safety and it's always a goofy "oh this API returns long and you used an int shame on you" when I logically know the value's going to be within Int32's bounds and sort of want to die if I get something out of that range.
I feel like dilettante has been burned by what usually passes for "Agile", the thing you get when management reads books and implements scrums and is actually too afraid to do the things that really make Agile. When I see this:
I totally agree. But then I scratch my chin and can't figure out why he puts that up as "better than agile". Everything past requirements gathering is key to operating on an agile team. You don't do deep requirements gathering because the process is designed for a world where the customer doesn't know what the hell they want, and if you sit and ask them you'll get a different answer every day. So you make something and ask them what's wrong with it. Then you fix that and try again. And you keep going until you're close enough to finish that deep requirements gathering because there's not much of a gap remaining.Quote:
There is no substitute for good requirements gathering, deep programming background, reasonable testing practices, and lightweight project management. No imperfectly understood ritual practices can make up for the lack of these things.
If what you write is well-defined and you can get requirements out of your customers, then cool, use a methodology that requires up-front design. My customers haven't signed a contract yet, and I can't ask them what they need until they're already customers. That involves a lot of rapid prototyping based on pre-sales interviews and being prepared to trash a feature if I get it wrong. Sometimes the sales guys even remember to let us do that prototyping before promising it to the customer. We can't afford multi-week requirements gathering missions, we prefer to deliver prototypes and ask the customer to tell us what parts hurt.
This part I agree with:
'Agile' isn't magic voodoo that turns a team of nobodies into superstars. It's an idea about approaching requirements as unknowns, and only investing in architecture as you start to clear the fog. I'd sure as heck prefer up-front design, but I think I'd be bored to tears in the world where every project has clear requirements from the get-go.Quote:
Then this is taken by shops, comprehended at some minimal level, and applied as a religion. The motivation is usually one of desperation to create silk purses out of sow's ear teams.
I think, metaphorically, the way to discuss whether scrum meetings and this or that process makes a shop "Agile" is similar to this I found in an old .txt file about karate I found as a teen:
A certification means you took a class. Delivering software on schedule in the face of unclear requirements means you're agile. You can print a lot of certificates in a day. You can't ship that many products, especially if you hustle.Quote:
The person who has earned it realizes that the true purpose of a Black Belt is to hold up one's pants.
I'd have to say that I feel quite unconvinced by that argument. It seems more like personal perspective, which I find reasonable, but don't share.
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
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."Quote:
Originally Posted by techgnome
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.
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."Quote:
Originally Posted by techgnome
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.
So, what you mean is one of these, right?Quote:
Originally Posted by dilettante
- 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).
But...but...my programs ARE fish stories! Half the time, I don't know whether I'm writing code or just cod.Quote:
Originally Posted by techgnome
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").
This was a scary trend.Quote:
Originally Posted by techgnome
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.
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).Quote:
But it /did/ work pretty well when I was paired with a newbie developer...
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.
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:
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 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.Quote:
Piiift! Paired programming... that's another idea that kind of came and went (under the guise of "Extreme Programming")
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.
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.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.
-tg