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?
... not because I like any of the technologies mentioned. Because if anyone in his position is so fucking stupid to feel the need to say something so obvious, they don't deserve that position.
He's just trying to get attention by hyping up "hype driven development." Maybe he shouldn't be hiring junior devs into roles well beyond their skill set.
Also, some things, are actually, worth the hype. Like Redis (compared to memcache)... many things aren't... And actually it depends on your use case.
Right tool for the fucking job. That's all he had to say... I'm tired of bullshit wanna be self-marketing tech assholes running off at the mouth.
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 ?
Stupidly followed the Ruby on Rails hype.
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...
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.
Rewriting half the application in mid development because the UX guy managed to convince the project lead/owner that "material design is the future of user interfaces!"
Lunch debates occasionally revolved around the plausibility of convincing a judge that this situation would fall under the category of "justifiable homicide."
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.
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.
Agile doesn't say you can't have big goals, only that the details can't be fully known up front.
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. The true requirements were not really known when the project started. The product owners thought they knew the requirements, but when the gears started to turn in production, they found that their original design was flawed, and had to be revised.
Agile accepts this reality up front, and does not attempt to fill in every detail at the beginning. It therefore eliminates a lot of work that would otherwise be thrown away during the waterfall revision process. Agile recognizes that fixing flaws becomes much more costly, when they are found later in the process. Waterfall does not do this, resulting in expensive change requests at the end of the process.
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
Then you did waterfall wrong.
Proper waterfall development involves actually talking with the customer regularly so that they know what is going on.
It's just so much easier to sort out what the extra costs created because of project scope changes are.
Learn how to do waterfall proper before you bash it.
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
I think a combination works best (waterfall/agile). There are some details you really, really need to know during the design as those details have a major impact. There is always some key pieces defining information which impact on everything. Like the key dimensions,entities or attributes in the database design. Get them and a few key relationships incorrect early on and you are in for a lot of re-work.
But after that, once you have that core worked out, you get get more agile and build around.
Just my $.5
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.
The TDD Kool-aid has apparently been drunk so deeply that NOT buying into an extreme test-driven development paradigm is "hype driven development", even though TDD is probably the best example of hype driven development there is.
^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.
Ignorance makes idiots embrace magical thinking as a religious experience, instead of pursuing computers with science. The decisions can often be driven due to politics and management, but developers pursue hype due to the positive influence the technology name can have on their resume for their next gig. If the project fails, it often doesn't matter when no technology positions last beyond a few years, at least for anything considered competitive.
> 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.
are currently in the over-hype cycle. We've been around and round on this on slashdot before, but most of the "justifications" for common usage are due to poor languages in my opinion, especially bad OOP design, and not to an inherent benefit of lambda's.
If you wish to say lambda's provide some decent work-arounds to poor language design, I'll accept that. But to say heavy lambda usage provides significant inherent benefits, I'll challenge it and ask for evidence and use-cases.
I won't dispute there are niches where functional may shine, but that's the case with a lot of IT tools.
Table-ized A.I.
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 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.
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.
But the company owner was the lead programmer.
So no hype-driven development, but the HR and "middle management" person did suddenly begin to send motivational emails,
and talk a LOT about the "team"....
He has become a proponent of the 'have you found Jesus Christ, our Lord and Savior' in the last 2 years, so the hype has become a little spooky....
Complexity went dramatically down and usability up once I returned from my roundabout back to Tcl/Tk. IMO *nobody* has got script/GUI integration as slick and unobtrusive as this gem.
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.
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.
Hype sells consulting. Consulting sells hype. Ever done a project with toilet and douche? How about ass-enter? How about Wipro/Infosys? All of them. They sell you on "this is the new way"..."you don't have the skills in house but we do". PHB's live for this shit. Its all they learned in MBA school. Wash, rinse, repeat.
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.
"pivot" == "we fucked up, start over"
I am very small, utmostly microscopic.
That's the first scam, to call s/w development Engineering with an E. The 2nd scam is Agile. The third is java.
Remove those three, and watch your productivity and quality soar.
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.
solves the same problems as C++, only worse.
Jack Welch got a lot of milage out of six sigma, because it was a pragmatic thing he was inventing as he went along, like agile. SOA works if every one is on board. A lot of "methods" do. But when some C_O gets on a plane and reads an article by some other C_O and gets all horny for the shiny new X method... he should just go to the little bathroom with the porn and not force it on an entire company. It took a lot of apathy for your company to turn to shit... it will take a lot of care to make it not suck again... no quick fixes.
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.
a few years ago I was hired as a contractor on a big government project. They had a large budget and hired about 100 medium to senior java programmers, juniors were not accepted. Instead of consulting the combined experience of these 100 people to make decisions about tools and technology, they let consultants and sales teams of big software vendors advice them to buy all kinds of expensive and bloated software packages. When I arrived at the beginning of the project it was in a horrible state. The productivity was near zero. People had spent most of the time with support calls, trying to install software packages or trying to figure out even the most basic features the customer wanted. As more and more developers got hired we had endless fights with the customer to convince them to ditch all this unnecessary packages. Also, the customer or his consultant had no clue about software development methodology: there was no version control, no continuous integration, not a single unit test. So we organized ourselves and introduced some tools. We made very conservative choices, like svn instead of git. We showcased to the customer how this improved productivity and quality and tried to convince him to also listen to us about the choice of tools and packages. After a year of stand-still the customer ditched all products and bloated consultant "advice" and we started over with a standard open source stack. Productivity skyrocketed. Finally we started to deliver, at an ever increasing pace. Then after half a year there was a management reorg: they created a java project committee to standarise on java methodology and tools . The leader of the committee had decided on some standards, separate from the project team, with the help of some consultants. Turns out a lot of our conservative choices were not conservative enough, we had to retrofit our code to older standards, no discussion. Productivity went down again. The technical choices imposed on us we made it impossible to use unit tests. Quality went down. At that point senior developers started to give up on the customer and left. They got replaced by the java committee with 'standards complient' profiles, clueless stubborn people you could not reason with. One of my co-workers got a depression. After one more year I resigned.
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".
How about the problem of the design team "wanting to move on to something else" and/or "has already booked a new project"?
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.
http://programming-motherfucke...
3D printing. End of story.
That's a terrible analogy. A better one would be this:
You're faced with a chasm that *might* be too long to jump across:
Waterfall design: you make the calculations and decide that you can just barely make it. You prep your takeoff area and sleep soundly that night, knowing your calculations were re-checked by a crack team of engineers. On the day of the jump there's a 20 mph headwind. You proceed to jump only to miss the other edge of the chasm by four inches.
Agile design: You make the calculations and decided that you might not be able to make it. You prep your takeoff area as the happy path, but you also add scaffolding stubs to the near end of the chasm just in case something goes awry with your plans. You don't get as much sleep, but the next day, seeing the 20 mph headwind, you spend a few hours adding scaffolding and a cantilevered takeoff surface that extends 6 feet over the chasm. You proceed to jump and easily stick the landing on the other side of the chasm.
Um... Ruby? Scala? Swift? No... never happens. Never.
This is my sig. There are many like it but this one is mine.
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
Sounds a lot like something Yogi Berra said, "If you don't know where you're going, you'll probably end up somewhere else"
yes, accountants thinking the cloud is a good idea.
great for storing an encrypted copy of your backup with a zero knowledge provider.
stupid for everything else if you have access to competent IT.
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.
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
Anyone do anything with WAP? I did :-(
We worked out a laptop setup where you could run a WAP app on the laptop, by dialling into it's built-in modem. You could use the demo (banking!) app using a Nokia 7110 phone (the one out of The Matrix). We had a hair-brained plan to sell the laptop + phone + demo app to people as a sort of marketing tool. Oddly, we didn't sell any, and never really did any major WAP implementations beyond maybe one closed beta. Even more shocking, the company more or less died shortly thereafter.
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
No, that's also a terrible analogy. Remember, resources are always limited, and in your two examples the resources expended on the two example "projects" are not commensurate.
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.
At my previous employer, one of the bigwigs came under the spell of a big name design firm (which had been brought in to modernize and harmonize the UI for the company's various applications). All of a sudden the company decided to go all-in on a SAS solution which the design firm had mocked up. Which might have been a good idea except:
1. The company had zero experience with application hosting, end user management, i.e. 90% of the solution.
2. While the mockup looked pretty, turning it into a functional application required whole chunks of new technology.
3. Because of all of the new technology, developers were pulled from existing products - delaying new releases of existing products (including the one I supported) indefinitely.
4. The business case was unproven and would require taking losses until a sufficient user base had been recruited - and the company wasn't in the best financial health.
5. Some of the SAS product functionality duplicated well known offerings by well established competitors - and the unique functionality could be duplicated by the same.
I smelled the woodchuck early on in the process and made my exit on my terms.
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.
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.
I'd give almost anything to work as a solo developer again. Being on a team is absolutely crippling to productivity. Invariably I end up working with retards (who slow me down), being directed by retards (who slow me down), or both. And then, having handcuffed me, they can't figure out why the project never goes anywhere.
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.
You're right. I still can't work with agile methods (I'm a contractor) so I might modify only my requirements gathering phase to use half-functioning prototypes that will allow the users to click here and there and see mock results. After getting feedback from the prototypes, I can be certain that requirements are as close to complete as possible. But at that point I probably need to stop, provide an schedule and cost estimate, and fall back to non-agile processes for the rest. What do you think?
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).
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.
Our company bought a vendor's software package (4 Million) and spent two years (with big $$ consulting services) trying to implement. The project leads went to a User's conference and were told, "The key to success is configuration, not customization", so they scrapped all of the previous development work, did a reboot on the project, and then spent another year and a half discovering that the core product did not work without customization, then spent another year recreating the customizations that made the product functional. Now the vendor is selling our customizations (redeveloped by them) as core functionality in their upgrades... Long story short, never run a development project based on a Powerpoint presentation.
JavaScript. Do I really need to say anything else?
Programming should use the simplest possible solution (and no simpler) for the task in hand - not whatever answer Google currently returns for the question "what is the best new programming language". Devs love technical challenge, and they love being able to speak with a highly technical (preferably new) set of words that lets everyone know how 1337 they are. No different really to music hipsters listen exclusively to obscure indie bands, most of whom are shit. If mgmt is not technically proficient enough to understand x,y,z hipster code and elucidate why moving everything to it isn't helpful in their specific application they can bow to technical "judgement" and end up with NoSQL where relationships are required, Angular js for flat web pages, etc etc.
Ever since the .com v1.0 era, tech has been driven by hype.
When was the last time you developed an engineering solution to address a problem, rather than to chase a fad? That's the whole reason Agile was developed -- because you don't know what you want to build until after it's built. It's the solution in search of the problem mentality. It's the difference between science and engineering.
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
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.
Good looking? Maybe to someone who was in a coma since windows 95 was fresh.