Slashdot Mirror
Ask Slashdot: Has Your Team Ever Succumbed To Hype Driven Development? (daftcode.pl)
marekkirejczyk, the VP of Engineering at development shop Daftcode, shares a warning about hype-driven development:
Someone reads a blog post, it's trending on Twitter, and we just came back from a conference where there was a great talk about it. Soon after, the team starts using this new shiny technology (or software architecture design paradigm), but instead of going faster (as promised) and building a better product, they get into trouble. They slow down, get demotivated, have problems delivering the next working version to production.
Describing behind-schedule teams that "just need a few more days to sort it all out," he blames all the hype surrounding React.js, microservices, NoSQL, and that "Test-Driven Development Is Dead" blog post by Ruby on Rails creator David Heinemeier Hansson. ("The list goes on and on... The root of all evil seems to be social media.") Does all this sound familiar to any Slashdot readers? Has your team ever succumbed to hype-driven development?
Describing behind-schedule teams that "just need a few more days to sort it all out," he blames all the hype surrounding React.js, microservices, NoSQL, and that "Test-Driven Development Is Dead" blog post by Ruby on Rails creator David Heinemeier Hansson. ("The list goes on and on... The root of all evil seems to be social media.") Does all this sound familiar to any Slashdot readers? Has your team ever succumbed to hype-driven development?
about Black Belt training?
I think infinite web pages was the worst idea that every site just had to copy to be part of the fad. I liked page number buttons. I can bookmark a page where I left off instead of scrolling a hundred times from the top again. It also doesn't use up all my computer's memory in Firefox or Chrome.
Many years ago I was working at a small company with about a half-dozen other programmers. We were all doing Informix 4GL and ESQL/C except for this one guy that kept to himself and never talked to anyone.
He was working on their next big thing - converting all the code to Informix NewEra or as some of us mockingly called it "New Error".
I left that place like a rat leaving a sinking ship so I'm not sure what ever became of them, but I'm pretty sure the NewEra product was never installed at any client site.
Main issue isn't "following the hype" -- it's not understanding why something worked for someone, or even why what you're currently doing is or isn't working before making sweeping changes.
PHBs making stupid and declarations based on trade magazines that sinks the project? Probably never understood what his subordinates were actually doing in the first place.
Developers changing languages mid-project? Forgot to add the time to master the language to the estimate, most likely.
Although, it was due to a sustained level of hype, rather than an epiphany by the powers that be.
Sig ?
It happens all the time. Everywhere. As soon as a trend arises on the horizon many companies jump on it to get their share of the cake. And it's even not unprofitable.
Slashdot, fix the reply notifications... You won't get away with it...
The problem is that experience can do one of two things to developers. Open your mind or close your mind. Many programmers refuse to open the Pandora's box and they stick to a tool, paradigm or coding style they know even though its not the best thing to solve the problem at hand. It's like a carpenter trying to cut down a tree with a circular saw because that's what he spends 99% of his time using.
I agree, this isn't an IT-specific issue. PHBs frequently make executive decisions base on what is promoted in trade magazines, which is a bummer for the workers who have to follow policy influenced by a marketing major.
Wow, ExtJS brought all development to a complete multi year halt. In the first few months ExtJS development is way way way faster than any other framework out there. But after about 6 months all you are doing is fighting with the framework. Just an endless knifefight. Any single problem could be solved against the base instlall of ExtJS but what happens is that you have to develop workaround after workaround to make the system snap into place for any given need. Those workarounds then make future "easy" changes impossibly hard.
So you might have something as simple as wanting to put the focus on a login username. If you had just done the page as your first round and thought of that then, like everything with ExtJS, a little weird but fairly easy. If you already have fought with sencha to make other things happen on the login page (say a filtered twitter feed) then ExtJS is probably broken 8 ways from sunday and you can't set a focus worth a damn.
Save yourself a world of pain and just use basic javascript combined with either simple single function libraries, or worst case scenario use a framework that won't blow up your company like react or polymer. Yes, you won't be a showoff in the first few weeks of development like you could with ExtJS, but you won't blow up your company when you can't finish the project until you realize that it can only be done by throwing out ExtJS.And if you get 5 or 6 people in the company who get training by ExtJS, good luck cutting through her bullshit about how ExtJS is the best thing ever even though the project is now 18 months late.
it must be good.
Or is it SOA? Or Java? Or Windows?
If all you've got is a buzzword, you ain't got a business.
Yep. Quite recently.
https://github.com/cloudtools/...
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Reaf TFA. These are exactly his points. So you are the idiot.
Many programmers refuse to open the Pandora's box and they stick to a tool, paradigm or coding style they know even though its not the best thing to solve the problem at hand.
Precisely the OP's point.
That's a typical trait of a junior developer, or an experienced developer who has worked solo for most of they're career.
For some projects and some teams, Agile is the best they can be expected to do. For other types of projects and other types of teams, it's a really horrible idea.
Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system. As Yogi Beara said, "if you don't know where you're going, you not get there." On small projects it might not hurt too much to figure it out as you go along, to backtrack and throw away code that has to be replaced. On large projects, and systems that need to integrate with other systems, you REALLY do need to figure out the requirements ahead of time and plan the architecture.
If your team consists solely of programmers of medium competence, Agile may be the best choice. If you have even one excellent systems architect, you're far better off letting therm do their job, planning the system out first. If your team includes junior programmers (or veterans who haven't expanded their skill set over the years), Agile can leave them floundering, going one direction for a few weeks, then another direction for a few weeks, then completely backtracking for a few weeks.
In summary, Agile is sometimes the best choice for your team, and when it is, you've done a poor job of hiring.
Several years ago my Pointy-haired Boss was reading technology articles (bad idea) and caught the "Big Data" bug. It spread to our CTO, CIO and all department heads like wildfire. This led to our Development team being turned into NoSQL zombies who said words like "Hadoop", "Shark", "Spark" in response to any new product requirement. It was a glorious vision of a magical backend system that would take all our data from every platform, that would scale up and out forever, and could be asked any question and give us exactly the results we wanted all instantly. The fact no one in the entire company had ever used any of the technology before or the fact we didn't even have any Java experience to setup even the base Hadoop installation were just minor points not worth discussing. I would like to say I was the lone dissenting voice, well I was and said lets just stick to SQL, but even I got caught up in the hype eventually.
18 months later and a sickening amount of man-years wasted and contractor money spent with no usable products or services the conclusion was NoSQL isn't a good fit for our data or platform use case. So they all went back to standard MySQL and completed 90% of the delayed projects in under 4 weeks.
On the plus side management heads did roll. I have a new My Pointy-haired Boss and CTO. However they have now started to drop in the words "Microservices" and "Docker" into all discussions. I can see a new hype-train arriving shortly ...
My development team isn't that particular flavor of retarded.
I disagree. Working at a primarily waterfall based company we have lots of change orders after systems go into production and as long as the code was designed well there really isn't an issue with adding new features. Sure, there are occasionally the huge changes that some customer decided they couldn't live without, but those types of changes hurt agile shops too. The problem you describe and "solve" is designing overly rigid code, not "agile is better than waterfall."
Wave.
Dialectician. Archology.
I used to work for a (bigger than small but smaller than medium) family owned business doing web development.
The CEO and President were brothers, they were the sons of the owner.
One of the two was the idea man. He'd see something on a competitor's website or he'd read about it somewhere and call a meeting to find out what would be needed for us to do it too. We'd discus it, start developing a plan and get to it and three days later, there'd be another newer, shinier thing that he wanted us to work on. It was soul-crushing because we never got to follow through on anything. I was very happy to leave that place.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
The problem is that people want magic solutions, and they keep chasing the latest fad in the hopes of finding the secret alchemy that will make average developers turn into gold stars, produce perfect systems in a tenth the time, and meet all requirements without the bother of knowing them.
Anyone who's ever done any system of significance that actually worked will know that the "best" tools and methods are situational. Need a bash script to list a few files? The approach is different than it would be if you're hired to redo everything used by the IRS.
We can go all the way back to the "shelf full of binders" methodologies. In their day, they were supposed to be the magic cure-all. Today, it's Agile, or it's XYZZY or whatever is the latest and greatest. Still haven't found that secret sauce.
One size doesn't fit all. There is no magic. Successful development projects require skill, experience, good judgment, hard work, and competent leadership.
Agile doesn't say you can't have big goals, only that the details can't be fully known up front.
The devil is in the details.
Why is Snark Required?
There's nothing preventing you from running an agile project with a robust and complete design. Agility allows you to pivot if and when required.
The easiest way to think of agile projects is a series of really small waterfall-like mini-projects that deliver a working product at the end. As you complete each mini-project, your product comprises a larger set of features. When your feature set reaches MVP, you can release or continue iterating to complete more features, but you can feasibly release at the end of any mini-project.
All of the arguments I've seen around [Aa]gile have shown that both sides are unwilling to concede that they don't actually understand the others' points of view.
There is no project that can't benefit from the ideas agile project management introduces, and there's no rule that says you should throw away your working model to implement agile (although it is generally easier to start with a single team that does start from scratch).
ALL projects benefit from measuring the outcomes of small, incremental changes and continually finding and limiting waste.
Leela: "Is all the work done by children?" Alien: "No, not the whipping."
Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system.
The problem is that waterfall is presented as making extreme effort to try figuring it all out up front, while Agile then becomes to the exact opposite where you make no effort and just prioritize what's right in front of your nose. Reality is that you need some flexibility in waterfall projects and some structure in agile projects. In my opinion it's fine as a development method, it's all the people making requirements who don't even try anymore because agile. We're so dynamic, as long as we can spin in place it doesn't matter that we're not going anywhere.
Live today, because you never know what tomorrow brings
Once upon a time I worked on an app that had 4 databases - MySQL, Redis, Neo4J and Influx. Each of these were to solve a specific problem (searching, time-series data, etc) even though the scale of the application (a handful of users per day) never warranted any kind of "big data" solution. And the fundamental problem remained - many of the developers didn't know how to write decent SQL.
Postgres / HSTORE could have probably solved pretty much the entire set of persistence use cases. But that's a solid, proven and ultimately boring technology. Where's the fun in that?
It's not just PHB driving the madness. Plenty of it comes from resume-driven development.
Thats why we develop our products in good ol' MFC/C++. It is still supported and that is not a coincidence. Who needs fancy things like reactive event streams when one can have the delights of MFC message pumps. Good old hardened, bare metal technology. Mobile plattforms, the Web and this thing called "Internet" are technologies we are happy to sit out and so should you. Trust me and thank me later.
Here are ten easy steps that you can take to implement Hype-Driven Development for your project.
1. First, choose a new tool. Find somewhere that the tool is being used by a company everyone has heard of. Don't be too concerned about what they're using it for, or whether it relates to your work in any way.
2. When you start using the tool, don't mention it to anyone until you've already decided to base your finished product on it.
3. Don't bother finding out if the tools you have can already do the job you're doing now.
4. Expensive tools are automatically better than cheap tools. This makes it easy to measure fitness-for-purpose.
5. Even if you only use the tool to simplify very mildly half a line of code that's only used once, incorporating a new tool is still worth it.
6. Compare the tool by re-implementing some of your existing tasks. Only test the simplest and most trivial scenarios: if it works in a simple case, it's bound to work just as easily in a complex case.
7. Any inconsistencies with existing standards can be readily overcome by creating a new standard that the new tool fits exactly. Try not to be disheartened by the idea that you've previously been doing everything wrong for years.
8. Have some like-minded suckers re-implement everything even vaguely related to the new tool from the ground up. The more suddenly you can implement this, the more of an impact it will have - and impact is always cool.
9. If the re-implemented product turns out to be awful, or if it doesn't do what users want or need it to do, you'll be committed to the new tool by then, so it won't matter. Tell anyone who is critical of the product that it's too late to change it and that they should have raised their concerns earlier - especially if they did.
10. Stride confidently into your next performance review, knowing that even though you wasted a lot of time and resources to build a product that does slightly less than it used to, you've certainly achieved a lot.
Attack its weak point for massive damage!
Does "whatever our Microsoft rep wants to sell us" count as "the latest thing"? If so, yeah, been there.
"The Greens lynched a hacker in Chicago. Last month, but I think the body's still hanging from the old Water Tower."
When Agile works, might it not be because the implementation was NOT actually being agile...
It's easy enough to build a personal filter that claims all (currently) working projects as "correct" implementations of Agile and claim victory.
After a lot of experience I personally think that success revolves a lot more around teams than process. Successful teams can usually succeed under a number of different process models, while no amount of "correct" process can save a team that simply doesn't work well together (or with the rest of the company).
A recent quote I saw on social media sums it up really well for me:
"Every software methodology attempts to fix the same problem: how to balance the urgent with the important."
"There is more worth loving than we have strength to love." - Brian Jay Stanley
There are two issues here, that need to be separated: Hype about development methodologies and hype about technologies.
If you have a good team, it doesn't matter what development methodology you use. It doesn't matter whether you have a scrum meeting every morning, or if you coordinate on a napkin over lunch - it's the team quality that matters. The rest is just formality, and provides a useful framework.
Technologies are more critical. Taking No SQL as an example: there are some very limited use cases where NoSQL makes sense, but there is a reason why 99% of the databases are still relational. Technical folks enjoy learning new technologies, but it doesn't take long to realize that there is no magic cure-all. It's the non-technical managers who get snowed by the marketing crap, and then try to dictate technology to their developers.
I worked at one mid-sized company that had put invested around 10 person-years in a new SOA application. Everything was looking good, and pretty much on schedule, but we had spent most of those first two years building foundation services that weren't terribly visible; the first GUI components were just emerging. Then the big boss got a visit from some Microsoft marketing weenie: "Wow, look at our new SharePoint - you can do anything with SharePoint". Next day comes a directive from the boss: Throw it all out, we're going with Microsoft. I dunno what planet he was living on, or what the marketing weenie offered him, but it took resignation letters on his desk to make him see sense.
Enjoy life! This is not a dress rehearsal.
^Question in the title ?
The answer is No.
aaaaaaa
...has proven itself for five years. The hard part is convincing executives of the five year rule. Often the benefits only appear in narrow niches or under specific conditions, but it takes a while for the industry to learn when and where.
Also, a lot "fads" are not directly technology fads, but rather obsessions. About 2 years ago our CIO became obsessed with SEO - Search Engine Optimization (Google hits, more or less), and so all kinds of silly games were played with our Internet content and CMS's, including mass repetition.
After a while people realized there was too much content to manage and clean up. That CIO moved on and the new CIO is a minimalist. Big change. SEO did nothing but make a mess.
We were suspicious of it all, but there was nothing we could do at the time but go with the flow. At least bullshit = jobs.
Table-ized A.I.
> There's nothing preventing you from running an agile project with a robust and complete design.
A large project with a complete design, an actual plan, may be agile (the adjective), but it's very much not Agile (the development methodology). A core tenet of Agile is that design, planning ahead to the end of a project, is impossible. In fairness, it probably IS impossible, for the people who believe that.
If they haven't been taught one particular trick, they probably never will be able to know the requirements before they write the code - trial and error really is the only option, if nobody ever told you the method to find out the real requirements.
If you want to know what the actual requirements are, there's one way to find out (and maybe ONLY one way). Sit down with the user and watch them work. Ask questions as needed to understand their workflow while they actually do it, and take notes. Ask the actual user, not their manager's manager, what they need to do their actual daily tasks. That way, (and probably only that way), your User Stories aren't fictional stories imagined by some manager, they are real descriptions of real users doing real work. Requirements flow directly from there.
That article from David Heinemeier Hansson wasn't that bad, actually. The title was truncated in the summary to make it more trollish.
He just said that he doesn't seek 100% unit tests coverage any more, and uses a mixture of unit and system tests.
It works fine in my experience.
That may be correct. The problem is widespread.
Microservices are not hype. Anything that lets you scale your code without having to rethink how you write code and while reducing cost is pretty amazing. If anything, I'd say microservices are underutilized these days, because it is often easier to start a new holistic system and architecture it for microservices than to convert aging systems to use a new model.
Look at their example:
Example 3: Microservices
Step 1: Big monolith application scales hard. There is a point when we can break them down into services. It will be easier to scale in terms of req/sec and easier to scale across multiple teams.
Step 2: Hype keywords: scalability, loose coupling, monolith.
Okay...sure. Req/sec and infinite scalability are a great reason to use microservices. Definitely worth having your brand new codebase use a microservice architecture. Whether your older codebase could benefit requires a cost/benefit analysis.
Step 3: Let’s rewrite all to services! We have a ‘spaghetti code’ because we have a monolith architecture! We need to rewrite everything to microservices!
You need a Step 2.5 with a cost/benefit analysis. How much time will it take to convert the code base? Do we really care about scaling to infinity? Where do we think we actually need to scale to in practice and how much benefit will we see from the architecture change? Etc...
Step 4: Shit! It is now way slower to develop the app, difficult to deploy and we spend a lot of time tracking bugs across multiple systems.
This step is kind of just wrong. Once converted most microarchitectures are actually faster to develop for if you've done things right, because you don't have to worry as much about scaling. The first question they ask you as a developer in your first job interview as a developer is probably about Big-O and time complexity. However, this has always mattered more for server-side operations than for client-side operations. If a server does something 1000 times slightly inefficiently, that inefficiency ads up. If an iPhone does something 1 times slightly inefficiently, it likely matters a lot less. In a microarchitecture model, the server is more like the client in the previous example, as each individual instance spawns and does its thing 1 time. Big-O still matters, but not as much.
Beyond this, problems deploying and problems tracking bugs across multiple systems likely have little to do with the microarchitecture itself. In my experience, microarchitectures can be as easy and are often easier to deploy than existing physical-hardware-based systems. For example, if you have many servers or many shards to deploy to, you may only have one deploy point in a microarchitecture or one production and one integration deploy point instead of a system of many servers. It's often easier!
Step 5: Microservices require a lot of devops skills in the team and with right investment might pay off as a way to scale the system and team. Before you reach serious scale issues it’s an overinvestment. Microservices are extracted not written. You must be this tall to use microservices.
Any new thing requires some learning or skill.
"Before you reach serious scale issues it’s an overinvestment." That sentence is wrong though. When you have no code yet it is often a great choice to use a microservice-based architecture, requires very little investment and can both save money and allow easy scaling. When you have existing code, but scaling and cost are huge priorities, it often is a smart investment of time. It's only in the middle stages where you have a large code-base you have to convert and don't actually need the scaling where it could be an overinvestment.
Big apple, new Yorik, undig it, something's unrotting in Edenmark.
I disagree.
The experienced developer has been chopping down trees for years with an axe. He's been putting up shelves with a drill. he's been cutting floorboards with a circular saw. And occasionally he's been cursing because he's having to make do with the wrong tool because although he knows what the right tool is, paying $lots for a tool he will use just once can't be justified.
Alongside that there are countless (less experienced) developers suggesting that he uses the circular saw to cut down the tree, the axe to put up the shelf, the drill to cut the floorboard and the experienced developer isn't particularly impressed.
But in the back of his mind he's always got that thought "what if that next tool is the chainsaw. " Just think how many trees I could cut down then. But even when the chainsaw comes along, he continues to use the circular saw on the floorboards, the drill for the shelves and, indeed, he may even still use the axe from time to time.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
I agree. I cannot wait for that fad to die an ugly painful death. Make the pages longer, that's fine. But not infinity.
I hear it causes ADA lawsuits. I hope so, sue 'em hard!
Similar annoyance points for the "flat" look. You cannot even tell a button is a button, and entry box boundaries are washed out. Shade the fsckers, people! It's not 1989.
Table-ized A.I.
> I wager that on every single waterfall project you have worked on, there have been numerous change requests after the project was supposed to be "done." If it was a big project, I wager there were many change requests. In other words, the original requirements turned out to be fiction
That was true until someone told me the secret to finding out what the REAL requirements are. Once someone told me the secret, I learned the requirements ahead of time and took notes of what they were.
If you want to know what the actual requirements are, there's one way to find out (and maybe ONLY one way). Sit down with the user and watch them work. Ask questions as needed to understand their workflow while they actually do it, and take notes. Ask the actual user, not their manager's manager, about what they need to do their actual daily tasks - while you watch them actually do it.
> only that the details can't be fully known up front.
If you're putting the details into your foundational core, if the design of the system as a whole is based on on the detail of some task, you're doing it wrong. Yes details change. It's best to do the details last, as much as possible, because even if you did know them, they'd change. And you know what? The finest level of detail that exists is executable code. Agile does code (detail) first, with the big picture (the design) as an accidental artificact seen only in retrospect. If you really recognize that details, things will change, wtf would you do the details, the code, FIRST?
The opposite idea is that because details change, you design an overall system, and architecture, then sketch the major modules within the system and when the plans for the major modules are validated, THEN you do the details, the executable code, LAST, after multiple rounds of validation. That way you not only have a better chance of getting the details right the first time, but as details change modules can be changed - the overall system, the architecture, isn't dependent on the details of any particular function. When some function needs to change, you just swap it out, plugging in the new version.
On the other hand, with the Agile concept of releasing executables within a few weeks, and releasing the bare minimum viable product, you start with code for important functions, then spend three years piling stuff on top of the *functional* code, rather than building the *system* first and plugging functuonal modules into the (designed) system. When the functions of your early Agile code needs to be changed, you're fucked because you've piled years of work on top of the feature.
Windows, Linux, C++, python, agile, scrum, ....
Every new technology raises hopes, PHBs make plans, and then technical people are left into the mud, and have to help themselves.
Strangely, this did not happen when we coded in FORTRAN IV, but for sure it wasn't the language that was up to expectations, we just had few PHBs, all of them had a *sound* technical background, and there was no internet trumpeting every minute a new technology that solves everything real now, soon.
You ask on stackoverflow, of course. *eyeroll*
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
It depends on if it really matters. A little script to pop up a box and let the user choose from a list of environment variables before running an application could be done properly with python or it could be done in a couple of lines using zenity in the bash shell. Sometimes using that circular saw is pretty damn quick if the tree is small enough that it doesn't matter.
That's why planning is important and choosing the technique before taking a major step is the way to get that experience. Solving toy problems or making small changes can be done with just about anything so that's not the way to start using the right tool for the job.
Well said.
CLI paste? paste.pr0.tips!
Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system.
Garbage, you simply show your ignorance. You know what? Agile is a meaningless term, you have some kind of image in your head of what it is (maybe informed by some group of idiots claiming to do it), and hence you can build this lovely strawman to set fire to. Here is the agile manifesto:
- 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.
No mention of not bothering with requirements, only that the emphasis when creating your processes is on the ability to respond to change. On any project that lasts more than a few months, that just sounds like damned smart idea. "No no! We must continue to follow this plan from a year ago, even though it no longer makes any sense in the current market!" Been there, done that, have the t-shirt. (You always get a t-shirt, no matter how big a balls-up it was).
I was once instructed to make an iphone app that would display content from an existing website.
There are golden tools which appear valuable but bend and break. There are bronze tools which make for lots of work and reflect poorly. There are also steel tools which work well and do the job. Unfortunately, there is no scientific deliberation in our community towards which tools are made of which alloy.
Reading Slashdot comments it seems that many seasoned developers are dismissive of some pretty good new tech, even after it's been around for much longer than 5 years.
C# is a great example. I'm a hard core C coder who mostly works on embedded systems, but when I need to do anything desktop I always consider C#. It might not be the most efficient language, but it's performance is perfectly adequate for a huge number of tasks, it has libraries that simplify most day-to-day stuff greatly and lets you concentrate on structure and architecture instead of details.
People around here often dismiss it because of the association with .NET (which itself is far from terrible) and the fact that it hides a lot of the "real CS" stuff, but that's the point of it.
Save the hate for stuff that deserves it, like Javascript.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
The boss's mistress was on our dev team of our +120 employee Japanese company. And then can Agile around. She didn't like it because it became so clear she was totally incapable and the team was always covering for her. But all it took was 1 complaint from her to have our boss storm into the office, yelling that his mistress would from now on would have to approve such changes. Needless to say, that wasn't a success either because suddenly everything needed her approval. We lost all our clients and most our top engineers within months. Within 7 months the company went bankrupt. That was after the mistress was quickly reassigned a new position somewhere else in the holding company.
Wow, ExtJS brought all development to a complete multi year halt. In the first few months ExtJS development is way way way faster than any other framework out there. But after about 6 months all you are doing is fighting with the framework
This is the good old "Rapid Application Development" myth that has been doing the rounds since before many of today's trendy agile NoSQL programmers and the PHBs who encourage them were born. Even with things like Microsoft Foundation Classes and Borland's OWL that were used to create substantial apps, the initial drag-n-drool honeymoon didn't last very long. Then when Multimedia came along there were more "authoring systems" than applications created using authoring systems, and they were all great until you hit the brick wall that the designers had never anticipated, and ended up re-writing from scratch.
"Ooh look, I can create a fully-functioning GUI app by clicking 3 buttons and writing 1 line of code... this is going to save weeks of development"
Six months later: "Ooh, look - I'm wading through the sparsely-commented source code of the framework trying to figure out why I can't get the 'print' method to do anything beyond the trivial case given in the sample project... what's this? '/// TODO - implement print function'...?" (Its too long ago for me to remember the details so I won't name the application framework in question).
Turns out that a couple of days writing the "boilerplate" code for your application paid dividends further down the line...
First example I remember was this: The Last One - yes folks, the last computer program that would ever need to be written, heralded by magazine articles predicting mass unemployment of programmers... but I'll bet you an internet that Ada Lovelace had some brilliant ideas for making the Analytical Engine take all the hard work out of programming...
Put simply: we all know that the last 10% of development takes 90% of the time. RAD tools eliminate the first 10% of the development thus ensuring that the last 10% takes 100% of the time.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
People around here hate C# (those that do) because it's from MS. When it comes to MS, there are no technical merits that can redeem the technology. They are not rational people. Most of them probably don't even program for a living.
I tried to use Java EE 6. When it was new. Using CDI and JSF2 and JPA2.
So. Buggy.
It was (is?) a pile of half-broken components that talked to each other over mostly-broken interfaces. Work around a bug, hit another bug. Work around that, hit a design oversight. All those portable APIs you're supposed to implement stuff against only actually work if you only use one implementation, if you try to actually run on both Glassfish and JBoss AS 7 for example, you're going to suffer unless your app is a toy or you do LOTS of testing.
For example... criteria queries? Kaboom, Hibernate and EclipseLink disagree on a lot of details. Subtly. Also, you have to drill down into the provider layer to get any influence over fetch control, so I hope you like N+1 SELECTs or monstrously inefficient chained left joins of data you didn't want anyway.
It was so awful I'm glad to be coding in C instead now.
FWIW I often compile with Mono because I like my tools to be cross-platform. I find that compatibility between .NET and Mono is excellent anyway.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Meanwhile, those of us who have more than a year of experience know that "waterfall" and "agile" are not the only process choices in the universe, we know how to plan for unknowns, and -- unlike agile -- we actually deliver reasonably finished products.
Trying to fit everything into single sprints is a recipe for code bugs and architectural rework. Making a toy version a higher priority than an appropriate amount of analysis and high-level design is a recipe for design errors and technical debt.
Zed A. Shaw pithily translated what Agilistas really mean when they claim to value those things.
Not that I endorse the idea of just "doing programming" as an alternative to understanding the project's needs, the team's capabilities, and using a process that fits both.
Yes it's as good as you would Expect and is the proper way to do an involved script GUI interface.
However sometimes a couple of lines of bash using zenity does the job and is pretty obvious to anyone who has to alter it later.
"pivot" == "we fucked up, start over"
I am very small, utmostly microscopic.
That is why we old-timers call them hypsters
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
I see developers using tons of third party libraries for no real reason. For example, one guy at a previous job wasn't liking the ability to use Oracle, which was the core database, so he had an instance of another RDBMS running as part of his codebase. Of course, this fucked things up royally come production and why some container files in a directory used for config files kept filling up.
Then, there is the fact that the more libraries you have, the more stuff breaks when a prerequisite gets updated. So the developer's crap who has a ton of garbage as a dependency is the stuff that breaks.
Want to know prerequisite hell? Run Katello. That is a program that is at best a house of cards.
I was in a shop that loved silver bullets. The fact that none of them worked should have clued management into the fact that silver bullets don't work. But they tried kept adding different things to their development environment such as new tools and methodologies such as Agile. And everything had to be Java. Doesn't matter that the existing application was working fine, and had been for years, it was going to get converted. They were even going to convert formmail.pl (it's been a while but I think that's the executable's name for Form Mail) into Java because they were a Java shop. They drank the Kool-Aid deep there.
I loved C# when I used it. We even used open source tools to build, test and deploy. It is/was a strong language. My issues were with being locked into the gac, IIS, etc.
Good teams usually mitigate the hype effect, because they are diverse in setup and bring along multiple perspectives.
I myself have fallen for hype a few times, as I guess we all have. I remember using Cake 1.2 beta, because "New Features!". ... Bad idea. Blew up in our face twice a week and delayed the project way too much. even discouraged from the core team. Typo3 was more of a local hype of German-speaking countries, but following that a little bit was more of a neccesity than hype.
I clearly remember consciously avoiding Ruby on Rails and smelling the hype from 10 miles away. Looking at how things turned out I'm glad I did. I have the habit of pondering for years about some new tool or toolkit. By then what to expect and what not has usually played out. Roughly once every 5 years I make a larger technology decision, and then only after having weighed the odds for and against it.
I'm currently doing this for Node & serverside JS vis-a-vis LAMP, my current breadmaker technology. I'm toying with the thought of moving to NodeJS and ditching LAMP, but I'm still not sure about it. ... We'll see.
We suffer more in our imagination than in reality. - Seneca
We agree about the importance of well-designed code. Poorly designed code hampers agile development as much as it does waterfall development.
My comments were about the requirements. Waterfall pretends to know the requirements up front, but then has to follow the project with a series of change orders. This happens because users often don't really know what they want until they see something in action. "Yes, this is good, but..." Because the change requests can't happen until the project is complete, they are relatively expensive to implement, especially if the changes affect the underlying architecture.
Agile assumes that these change requests will happen, and focuses on reducing the cost of the change requests. By getting software into the hands of "customers" very early in the process, these changes are found much earlier in the process, when it's relatively cheap to change the architecture, if needed.
There is a reason that waterfall timelines are measured in quarters or years, while agile timelines are typically measured in terms of days or weeks.
There is no inherent quality difference between Agile and Waterfall, in my experience. The difference is in how the project is broken down into small pieces, and in what order those pieces are carried out.
Exactly! So when waterfall tries to nail down the details up front, it does itself a disservice. Users find out months later that those nailed-down details don't quite work for them, and now you have to go back and re-engineer your project. With Agile, you find out much earlier in the process that the details weren't right.
I work for a company that makes apps. We rushed to release an Apple Watch extension as quickly as possible after the Watch's release, for the sole reason that we wanted to be able to issue press releases about how we support Apple Watch and are super-innovative while our competitors are not. Nobody thought it would drive sales from a feature perspective, except insofar as it could create the perception that we're "cutting edge" and "innovative". Never mind the fact that our Watch implementation was extremely crappy; we got mentioned in a NYT article for being "first".
ALL projects benefit from measuring the outcomes of small, incremental changes
Not all. You can't jump a chasm in several small jumps.
and continually finding and limiting waste
No process I can think of accumulates more waste than Agile, with half-written features that went nowhere, hooks for removed features, and features that belong together chopped up into ineffective pieces with extra interfacing in order to get one piece done in a sprint. It begets bloat, but that isn't necessarily a problem that dooms it. It may still be preferable to having nothing that works as release nears.
But a good example of where Agile just doesn't work are projects with outside limits in the specs. They could be IO limits, CPU limits, response time limits, or otherwise. As a project starts, everything is comfortably within all limits, and they aren't given full attention, because whatever else comes down the line isn't fully known. But as the project moves on, the limits no longer are far off uncertainties, and reality hits hard. Good portions of code already written has to be scrapped and new algorithms made, because if you have already used up 100% of the available IO and response time when the project is half-done, tweaking isn't going to solve it. What management sees is that the Agile team committed to doing a job within the constraints, and can't deliver.
Yes, continually finding and eliminating waste is important. But refactoring code isn't the major part.
Waste is often personified, and being able to get rid of people (including ineffective managers) can be far more fruitful than trimming unused elements from a struct.
This industry is nothing but a succession of fads.
Um... Ruby? Scala? Swift? No... never happens. Never.
This is my sig. There are many like it but this one is mine.
There is a reason to hate C#. It is effectively controlled by a single corporation. Don't give us bullshit about it is "standard" or "open". It isn't. It is Microsoft. It doesn't matter if it is Microsoft or Google or Sun or Apple or whatever, it is still controlled by a single corporation. C++ is open and standard.
Reading Slashdot comments it seems that many seasoned developers are dismissive of some pretty good new tech, even after it's been around for much longer than 5 years.
C# is a great example.
Lets assume that C# is, indeed, better than sliced bread.
However, in a linux shop with no C# development at all, no infrastructure to support it (mono?) and nobody who is knowledgeable in the tools, config, support, failure modes or problems, is it wise to "jump ship" from whatever technology is working currently?
I'm not saying it's definitely wrong but, changing to use C# isn't an "agile" thing. One developer who knows about it and can support it on his own desktop, can probably make it work - but can he make it work across the company more cost effectively than not adopting it? It's a business case that needs to be made.
And if that evangelist decides to leave after nine months because getting a company to adopt a "new improved" language turns out to be bloody hard work, will the company be able to continue with the investment so far or will it decide to go back to the tried and tested?
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
People that don't like C# (like me) don't like it for a number of reasons starting with lock-in, sub-standard libraries if you're wanting to be cross-platform, etc. C# was a reworked clone of Java after MS-Java was found infringing. The CLR is interesting, but is a fundamentally different solution than the VM approach used by the JVM. It solves the many languages running on Windows problem, not the run language X consistently across multiple architectures and OS problem. Hence the lock-in issue, because if I'm going to run on Linux, I'll use Java, not C#, as C# offers me nothing compelling to use it on various flavors of Linux, BSD, OSX, OS400, etc. And no, Mono isn't good enough and EF (ORM) isn't a reason either.
The cesspool just got a check and balance.
But usually not as much, because with shorter development cycles the customer has the opportunity to realize they need the changes earlier.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I'm more pragmatic. It gets the job done, if it compiles with Mono today it will compile with Mono tomorrow even if Microsoft decides to change something and make it proprietary.
If I'm writing a tool to do X today, how exactly do you think Microsoft will use their control of the language to cause me problems later? I can only imagine fairly outlandish scenarios.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
I dislike C#. I have programmed with it, C++, and C as well, even relatively recently. For my particular purposes, C/C++ wound up being far better languages to code the system I needed (on Server 2012) than C#. I needed system calls that required calls into the Win32 subsystem directly, and if I need to write a library in C anyways and call it via a lightweight PInvoke wrapper, why not just write the entire thing in C and skip the extra complexity, overhead, and debugging headaches?
The cesspool just got a check and balance.
Sounds a lot like something Yogi Berra said, "If you don't know where you're going, you'll probably end up somewhere else"
I started in the industry in about 1976, can't remember exactly, too old.
However, ever since my entry (and probably before) the whole industry has been trend and hype driven. Death of goto and spaghetti (haha alive and well), thin clients (no alternative when there were just VT100s), then thick clients (PC), then thinnish clients (PCs without a lot of power), HIPO (instead of flowcharts), various design methods (Jackson, structured etc), waterfall , spiral, pair, agile, peer, client-server, objects-bad (things that modelled data and code in the same 'space' considered bad), objects-good, object-Stalinism (everything is an object, if you really push on it), functional and we're about up to 'now'.
Then, of course, succession of languages, Cobol, PL/1, Filetab, C, C++, Python, Perl, Ruby, Javascript and now frameworks, Ruby on Rails being the frothiest in living memory. Not forgetting Codasyl, Relational, NoSQL and Graph (Neo4j etc.) until the next thing.
An optimistic view would be that all this is 'progress', but (call me old and cynical, I am) one can make a mess with any methodology, architecture, framework, and language, however ancient, however modern. That said, I'm against most of the agile school because I constantly see quickly added, ill-considered, unnecessary, architecture challenging, and undocumented features being added because "we're in a sprint", this is the current version of 'make a mess faster'.
On y va, qui mal y pense!
As I once stated in a comment around here, I have seen loads of over-engineering hours wasted by Android dev teams trying to fit a square peg to a round hole: many a times MVP/MVC or other "responsibility containment" patterns refactoring hours are applied to existing, super complex activities that will never be reused; other times applied to super sort activities that need no testing. This cuts 2 of the more relevant benefits of refactoring (testing and reuse). I see technical debt tasks so often, just for the sake of "patternizing" things, without a clear long-term goal (or even a problem to begin with), save for cargo cult programming - 10-file activity modules with 10 LOCs each, when the same could be achieved with 2 or 3 class/interface files providing readable and conceptualizable code still keeping the same testability and re-usability. Even starting something from scratch is no excuse to make it "standardized" - you start with the basics, and when you find reuse/testing/containment problems, you decide to change to a complex approach.
And this is for Android: an already complex, well engineered API that intrinsically forces you to separate responsibilities, and is a reuse/testing heaven. I like most of the SDK and it does look clean. This is so because it provides thousands of official and community documentation pages. You don't see that code and doc quality from small teams that define set standards and work on a fraction of Google's budget (read: more man-month AND more punch per "man"). All in all, most benefits of advanced software engineering are lost, in practice, when applied by small software houses. This is why I believe that even though patterns have a purpose, its benefits are tightly coupled with good judgement of its usage. Over-engineering is a serious disease in the industry.
People around here hate C# (those that do) because it's from MS. When it comes to MS, there are no technical merits that can redeem the technology. They are not rational people.
The complaints I've heard didn't generally sound so irrational. I thought the consensus was "It seems like a good language, but still most useful in building things for Windows. Maybe that will change as the cross-platform stuff improves, but for now, I'll stick with [whatever language they're using]." Admittedly, I'm not a real programmer and only get a sense for what programmers think from this site.
In my experience most developers seem to be emotional and illogical. They have deeply ingrained beliefs; sometimes that the legacy tech is the best and sometimes that the latest new thing is the best, and they will not reassess their position regardless of real world evidence. Personally I try to keep an open mind and use the tools I am given.
putting the 'B' in LGBTQ+
By all accounts Donald Knuth—almost all by himself—ran circles around the Agile team (this was a full two decades before the first glint in eye of the Agile Manifesto) and yet the world has not adopted Literate Programming.
Suppose I were to acquire an Agile development shop, one with a track record of making their chosen process work. Then, surely, a year later, I could write the following:
Literate definitely works better than Agile in the 0.001% of the programmer population—to offer up a perhaps hopelessly optimistic estimate—who are a) brilliant mathematicians, and b) semi-brilliant architects, and c) brilliant expositors, and d) know the algorithmic literature inside out.
Agile works well when the glove fits the talent (it would not have worked well for Knuth).
This is not new. Many other gloves have demonstrated the same success model. What every workable model has in common: hire the best people, and then create a culture where the best people can most effectively drag the rest along.
The other way this plays out is that a sub-group of programmers who are a little better at politics (and a lot noisier) agitate toward their particular approach to life being flattered by the best-fitting glove. Then, instead of people being judged by where their talents are the best fit, the story becomes square programmer fails to fit round hole.
Agile is far from the roundest hole. Literate is a hole so round it unbreaks broken symmetry. What's great about Literate is that it's so obviously too round for the human species to endure, it's almost never forced upon anyone unsuited to its strictures. Instead, Lisp and Haskell (and APL within a smaller niche) take the crown of being the roundest holes into which any programmer has been forced against his or her aptitude and self-interest.
Agile is good at managing specification risk. If managing specification risk is the top of your risk pyramid, it's proper to ask whether forcing people (whose natural fit lies elsewhere) into a rounder hole is the right business method. What drives specification risk? 50% of this is driven by ambitious yet curiously clueless customers. These are never in short supply, so Agile is rarely in short supply.
What drove Literate? The case of a curiously over-competent customer (Knuth wrote TeX first and foremost for himself, to typeset a sophisticated manuscript he had already authored). These have never been in large supply, hence Literate has never been in large supply.
Even with top talent, the fractal repeats. PHK hates Literate, and he's neither second rate nor inarticulate. What happened there?
Move my rants into their own sandbox
Millenials are worthless programmers. Your IDE's are for girls. You don't know how any of your tools work. Now get off of my lawn!
Too often developers choose to use a technology because it will look good on their resumes, not because it serves the interests of the system's users or the people paying for it. It's what economists call "agency costs".
Every time a new golden hammer comes up, developers rush to use it before they get left behind. And you can see the corrupted focus right in the code. I remember when Model-View-Controller was the buzzword du jour, and people without any sense of irony whatsoever would bake MVC framework dependencies into practically every single file. Ugh.
But here's the rub: part of taking care of user and customer needs is considering the impact of future brainshare. Sure, COBOL may be just perfect for this app (OK, probably not), but should you really saddle them with having to find someone with COBOL expertise? It's possible to be too puritanical about avoiding technology fads.
So part of your job as a developer is to track the emergence of new golden hammers, to study good and bad examples of their use, and to truly understand each of them as much as possible. Where possible you should try the latest thing; if you're a team manager assign slack personnel to do spikes that evaluate it (this is a great perk to hand out). It's part of your job to stay on top of where things are going, without committing customers to something that might not meet their needs.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
What almost everyone gets wrong about agile is confusing the agile methodology with specific implementations of agile project management. Scrum, Kanban, Extreme Programming, Pair Programming, or any other agile techniques do not define the methodology itself. One of the reasons there are so many different agile methods and practices is the realization that no one method could work for any project or company. But the core tenants of agile development, just like the core tenants of the SDLC, PMBOK, Six Sigma, etc, could be applied to any project to great success.
Central to Agile is the proposition that the company is unable or unwilling to figure out what the requirements are before they develop the system. As Yogi Beara said, "if you don't know where you're going, you not get there." On small projects it might not hurt too much to figure it out as you go along, to backtrack and throw away code that has to be replaced. On large projects, and systems that need to integrate with other systems, you REALLY do need to figure out the requirements ahead of time and plan the architecture.
The core tenant of agile you are referring to is the realization that business needs will change or be further realized at every point in the project life cycle. This is not something which is up for serious debate for any project management methodology. You cannot know every requirement up front, changing or unknown requirements are far less unavoidable than death and taxes. Even a tightly managed project like sending the Curiousity rover to Mars required code modifications even as the craft prepared for its descent to the planet.
There are plenty of ways to manage changing requirements. Various agile methods are among those strategies. I happen to agree with the agile tenant that changing requirements should be embraced as a way to create better software, instead of something to be ignored so you can follow a pre-determined plan. This is a mindset I have even had on my "non-agile" projects (which includes the vast majority of them). The two main barriers to successfully maintaining this mindset is architecting software well enough to handle change and managing business expectations to accommodate change (which usually includes modified scope of impending releases). Every project can be handled this way, but not every company or development team is managed well enough to accomplish this. Managing business expectations is usually the most difficult part and where most agile teams end up failing.
If your team consists solely of programmers of medium competence, Agile may be the best choice. If you have even one excellent systems architect, you're far better off letting therm do their job, planning the system out first. If your team includes junior programmers (or veterans who haven't expanded their skill set over the years), Agile can leave them floundering, going one direction for a few weeks, then another direction for a few weeks, then completely backtracking for a few weeks. In summary, Agile is sometimes the best choice for your team, and when it is, you've done a poor job of hiring.
This seems very inconsistent. You say agile is the best choice if you have done a poor job of hiring, but then admit that agile is hard to do right with a junior or otherwise poor team. I do agree it is difficult to run a software development team in a highly efficient way with a poor team, regardless of what project management methodology you use. But I disagree that agile is less useful for very experience staff members. I think this is where it shines. Architects can focus their design at different levels of abstraction and in different contexts as it suits their current tasks. Nothing in agile stops designers from doing up front design and architecture, just from doing more than is necessary. It is very hard for inexperienced staff to know what is necessary, however, but this is much less of a problem for highly skilled employees.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
I worked at Accolade when it got bought out by Infogrames, which later changed its name to Atari after buying Hasbro Interactive, which owned the Atari intellectual property rights. The CEO pushed for every game title to be available for every platform (Microsoft Xbox, Nintendo GameCube/GameBoy Advanced, Sony Playstation 2). That worked well for some titles. But not all titles were suitable for all platforms. The multiplatform strategy fell apart when Nintendo rejected the PS2 ports to the GameCube and demanded that each game take advantage of the GameCube features. The dot com bust didn't help. The company sold studios for pennies on the dollar after paying two to four times more than what each studio was worth during the buying spree. Bankruptcy came and went again.
And which C++ variant is that?
Java.
In your other post you said:
> What almost everyone gets wrong about agile is confusing the agile methodology with specific implementations of agile project management. Scrum, Kanban
I'll admit I'm doing this a bit, specifically thinking of SCRUM, as the main example of the most popular Agile methodology.
> Try asking a salesman using spreadsheets and Outlook what he wants out of a new CRM implementation and see how far that goes. If you think that is sufficient to get good requirements
If rather than asking, you do as I suggest and WATCH what he actually does, taking notes and asking questions, then you know exactly what his *requirements* are, what the system must do in order to allow him to do his job. While watching, I like to listen for not only him but people in nearby cubes/offices making exasperated grunts or cussing under their breath, and ask them what most frustrates them as they work. Those are probably likely requirements for a better system!
> Showing users working demos
In my experience (20 years), that's useful, but very much not sufficient. They a) focus on how pretty the interface is, not on the needed functionality, and therefore b) assume that all needed functionality will be there, implemented how they need it.
A great hybrid of the two approaches might be to WATCH the user (rather than show the user) using a mockup / demo. Say "show me how you'd do your morning routine using this mockup instead of your old tool". You might tend to get a lot of "okay how do I find foo?", where foo is something critical to them, that was never mentioned is requirements discussions.
MS has been burning people for decades. After being burnt 4 times in the past, do you blame somebody for not wanting to risk being burned 5?
Silverlight, Active-X, VB-Classic code, FoxPro, IE bugs, most of their mobile crap, etc. etc.
Maybe MS sometimes is accidentally nice and won't pull the rug out from under you in the future. But, how does one know THIS time is such a case?
Look what Oracle has done to Java "standards". C# could be Oracletized if MS gets desperate enough for cash one of these days.
(The one possible upside of MS is that it's easier to find developers for. Even if their tricks and flops force you to re-write, at least the rewrite team is fairly easy to put together. Their ubiquity makes reinventing the wheel a bit easier. )
Table-ized A.I.
You may not borrow my circular saw, ever. The problem with that assumption is that all of the reasons for using the right tools (axe, chainsaw) are gone; no sap, the tree is all dry wood, there are no fibrous sections in the bark, etc. That is the same problem I see all the time with evangelists for any tool. In order to make a rational, evaluated decision, all facts must be looked at as objectively as possible. Or to use an old quote "the right tool for the right job".
You can have it fast, accurate, or pretty. Pick any 2.
This also depends strongly on the project management style and customer demonstrations. Generally I get change orders for plenty of things before the software ever hits site. This is because we do design reviews throughout the project, we have a live Factory Acceptance Test with customer in a simulated and emulated environment, and we specifically structure things so that we can get requests for change earlier. Now, granted the type of system I am installing can't be piece mealed out therefore we are somewhat pigeon-holed into waterfall, but with better transparency and avoiding developers all working in silos this isn't such a problem.
Some of our core development is done more in agile style with feature specs, sprints, and such, but if a common sense approach is used waterfall does not have to be so back loaded and so much more expensive. I would argue a lot of those problems come from large organizations that allow their gears to grind much too slowly and they isolate people so that they don't actually look at the overall business problem they are trying to solve (so that they can predict what parts of the code need to be more flexible).
Granted in some scenarios I do feel agile is more well suited, because it is a good thing to allow the user to get more hands on time with the end features so things can be tested and retooled if it isn't what they want, but a project can still be managed in waterfall style as long as proper measures are taken throughout the process, at least in my opinion. I know some people are married to one style or the other, but I can't help that.
As I stated in my other post, if design reviews and early on demonstrations are done a lot of that can be mitigated in a waterfall project. I concede (and wouldn't really ever say otherwise) that some things will fall through the cracks, but my statement was that can happen in an agile environment too even though it probably happens less. I mean hell, sometimes even customers can be pushed by hyped up posts about new technologies (see: the cloud when it first got popular...) that they really don't need but someone wrote an impassioned article and they get convinced that it just has to happen right now.
In my 27 years in software development, I've never worked on an Agile project that failed to deliver finished products. In agile, the initial coding becomes part of the analysis and design phase. Agile does not mean less (or inferior) design and analysis. It just changes the method and sequence.
Every waterfall project also has technical debt and design errors. That is not specific to agile. In fact, because waterfall attempts to complete the design without anything concrete (i.e., working) for customers to see, it becomes much easier for bad designs to become buried in the reams of documentation.
I'm glad you can see the need for a spectrum of different methods, to suit different needs. This is key. No single methodology works for everything, or everywhere.
Actually, this is what keeps so many developers employed. When software becomes overwhelmingly difficult to maintain due to sloppy development and project management practices, managers come to believe that the solution is switching to the latest cool technology, and a rewrite begins. Eventually, since the underlying sloppy methodologies remain in place, the cycle repeats. What drives this cycle? Managers, team leaders, customers, stakeholders never want to admit that they are the problem. It's human nature. So, c'mon Micro-services, heal us!
Some settling may occur during posting.
We are in the depths of OSD hell. MDT>OSD is frying pan to fire!
I'm a perl programmer, almost by definition I don't get hired by places that insist on chasing the new shiney.
The tendency of programmers in general to be as trendy as a bunch of teenagers has not been lost on me, however (like I said, I'm a perl programmer).
Somewhat more disturbing is a tendency of perl-culture in general to be a bit faddish... one year it's inside-out objects, the next year it's the Moose family, one year Module::Build is the greatest, the next Extutils::Makemaker has made a comeback and no one wants to hear about anything else, one year ORM are the bees-knees, the next it's the NoSQL fad, then it suddenly dawns on people you don't really want to try to do schemaless data...
Absolutely. I actually get sideways with people that think one specific method, language, or tool is so good that it should always be used no matter what. Flexibility is key not only in code but on the business side of software development. Getting good with more common languages/methods/tools/etc. is great in the sense that they will be used more often, but anyone that has an almost religious devotion to these one thing may succeed with it in short term (and there are still too many that believe this) but eventually a problem will come along that needs something else and they are will try to force the proverbial squares into circle holes.
"Stop planning and start doing" was the greatest piece of wisdom I got from my American boss many years ago. I suppose you'd call it "agile" these days (is that old hat now? I dunno). You can over-plan something, and whilst my reply probably has little to do with "hype" as such, you can focus too much on the latest buzzwords and frameworks. Just stop planning or thinking too much and dive right in. At the time when I heard "Stop planning and start doing" most of us thought the guy was crazy, but years of development have shown he was right.
I could only have delivered half of what I've done over the past 5+ years if I had to use something other than Ext JS. I chose it mainly for the superior grid and its excellent data package, which are still at the top of their game today. I don't know why something like setting focus eluded you so much, so perhaps something else was going on and getting in the way (I've painted myself into a corner countless times and wanted to blame the framework, but in most cases, it turned out to be my own fault). And as for workarounds, occasionally you might need to put one in place to solve a bug ahead of the next release, but that's not often (no framework is immune to the odd bug).
The great thing about Ext JS is that it gives me pretty much everything I'll ever need. Now I doubt I'll impress the "hype" crowd with that statement but I don't have to manage all those project dependencies and includes and various build systems. But at the end of the day, I don't care too much about the inner-workings of Ext JS because my finished products are so darn and good looking functional, and this continues to be one of its strongest selling points (albeit with a much heftier price tag these days, but it's still worth paying, IMHO).
The problem is that experience can do one of two things to developers. Open your mind or close your mind. Many programmers refuse to open the Pandora's box and they stick to a tool, paradigm or coding style they know even though its not the best thing to solve the problem at hand. It's like a carpenter trying to cut down a tree with a circular saw because that's what he spends 99% of his time using.
That is true enough, although if we got into specifics I think everyone would be guilty of this to some degree. C++ / Java style OO, for instance, appears to have irreversibly poisoned the minds of at least two generations of coders because it's "good enough" and very familiar. They even celebrate the fact that they have to repeat certain familiar patterns of code over and over in a noninuitive way to accomplish some commonplace task, calling such kludges "design patterns."
On another note entirely, I simply can't resist mentioning that when I was three years old I actually saw my father cutting down a small dead tree in our back yard with a hacksaw... and I asked him why he wasn't using his portable circular saw. He paused, muttered "that's actually not a half bad...", went to the garage and used his circular saw to finish the job. (He didn't have a chainsaw.)
I'm not sure what that tends to argue for except, perhaps, for the fact that I was apparently a hacker from a fairly early age.
You forgot to mention two developers, but only roast one. You know know those guy that learns about a new technology that the team has never heard of, convinces the boss through their evangelical zeal, writes the feature, then proceeds to bail / quit because the company is just too passe. Now the team's left with a half-broken feature and a new core dependency boat-anchor left for someone else to eventually remove in a future release.
The sad thing is, I'm far more of this guy than the stale one, but years of dealing with other people's research f-up's have tempered my zeal to much more realistic ends.
Bye!
I know someone like you. He thinks henis the worlds greatest programmer but he is as dumb as a brock. His problem is that he uses very inefficient tools.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
People around here hate C# (those that do) because it's from MS. When it comes to MS, there are no technical merits that can redeem the technology. They are not rational people. Most of them probably don't even program for a living.
As a former Visual Basic programmer I will not base my livelihood on a MS programming language. Who knows when MS announces the next shiny programming language, declares my companies existing code base obsolete and expects everyone to repeat the same mistake.
I do not view this as irrational in the least.
You misunderstand.
Sometimes the task is such that there are a vast number of right tools to choose from.
At other times there is not.
I have never created a correct design without prototyping it first in the same language it will be developed in. I am possibly just really bad at design and architecture but I see people sticking with bad architecture all the time when the language forces them to be completely unambiguous about there thoughts. I see this a lot. My preference is to brainstorm then jump straight to coding a prototype. When the prototype passes the prototype passes my prototype tests I take credit for finishing the design. If they knew it worked they would want to ship. Then I write it again with lessons learned and call the code 25% complete. Then I write the design with lessons learned and call the code 50% complete. Finally I write the code a third time with further lessons leaned and declare code complete and move on to formal test. I deliver on time because even though this seems backwards and excessive it is faster (for me at least) than trying to think it out in advance without prototyping and then being stuck with a bad architecture that has to be updated (if they let me).
refactor the law, its bloated, confusing and unmaintainable.
Python's open and standard too, that's why Python 2 is still the most common variant.
Karma: Poor (Mostly affected by lame karma-joke sigs)
Experience counts for naught. Most developers with 10 years of experience just experience the first year ten times over. Many big tech companies confirm this with their talent search issues. Statistically there is virtually zero difference in skill between someone who has 6 months experience or 20 years. Most people quickly reach their limits.
In my many dealings with world grade technology consulting firms, they are horrible at consulting, but they do make for great human interfacable reference books. Most of the time I spend about 5 minutes reading a Wiki article about a given technology before jumping into a meeting with a specialist, then I poke holes in their logic until their ego is bruised enough to get them to be quiet, then I start asking my questions and finally get somewhere. Their logic and understanding is almost always horribly flawed, but they do know a lot. Their opinions are pretty much useless.
They may know more facts than I do and have dealt with more issues that I have, but I will have vastly more understanding of the domain than they will ever have. Cargo-cult, that is all.
JavaScript. Do I really need to say anything else?
Actually, this has been a problem where I work for almost two years now. It's the ADHD approach to development or as I like to call it 'the Ooooh something shiny' paradigm. It's kill productivity, run off several very good developers and has murdered our customer base to the point where we're losing customers, not gaining them.
Of course, management blames everyone/everything but themselves for this debacle. Personally, I'm glad I'm leaving here the end of January.
Pax Vobiscum
You don't have to use your imagination, and what you appear to think fairly outlandish scenarios have happened. I don't expect C# to go the way of VB (not VB.NET) or Silverlight any time soon, but despite cross-platform efforts it's still pretty well connected to Microsoft. C++ and Java, to name two, have strong communities not tied to their originating companies.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Remind me, what were the open source implementations of VB and Silverlight? Where was the open spec for those languages? And why did all the software written in them suddenly stop working when Microsoft ended support?
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
If your team consists solely of programmers of medium competence, Agile may be the best choice. If you have even one excellent systems architect...
What you're ignoring, is that for a hell of a lot of real-world projects, there's already a pretty good architecture in the form of one of several appropriate frameworks--and in many cases the team is already using one.
There's really a small portion of software development that is cutting-edge.
Sometimes the larger system is already built, and all that remains is to add small modules which conform to the well-defined, well-documented, and enforced rules of the system. In that case, you have a number of small projects, and most any methodology will manage.
If you're designing a new system - well then the SYSTEM should be DESIGNED. The architecture of the overall system shouldn't be the accidental result of however different people shoehorned different things in during different sprints. Programming frameworks, as the term is normally used, are not at all the same thing as systems architecture. To be frank, this sentence:
> There's already a pretty good architecture in the form of one of several appropriate frameworks
Makes about as much sense as this sentence:
You don't need a map; there's already a pretty good route in the form of several appropriate vehicles.
Sometimes a framework can be useful, but it's no more an architecture than a car is a route.
Presumably, they were working on a code base smaller than a linux kernel, and saw no technical advantage in subjecting themselves to git's incoherent user interface. We're talking about hype driven choices here, git is a fine example of the software industry going crazy with a fad and dropping a productivity bomb on itself for six months while trying to figure out how to make the fad work.
If you don't care about future language development, you're probably OK.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Good looking? Maybe to someone who was in a coma since windows 95 was fresh.