The blueprints is the requirements and planning stage, with API definitions. This does involve iterations. Coding is the building process, where checks (testing) validate the components before the next layer is added.
I design and build a data store, complete with an API in between. (the Foundation) It was designed with certain requirements in mind, because performance is a key metric I'm going to be measured on when it's done. Some Agile moron comes along 6 months later, and decides that he needs to filter with permissions in a new way that the DB was not designed for which works with today's traffic. Ideally this change requires a new foundation, because now, instead of an arch bridge, we're building a suspension bridge. The foundation requirements changed, and if we were doing it right, we'd tear everything down, but in the agile world we just slap some extra code (mortar) on the foundation, and voila, it runs/stands. Then traffic doubles, and the bridge fails.
You will pay the piper, sooner or later. Agile advocates later, which is why it's so popular with business types. That's fine if you never plan on being anywhere longer than a year or two, and don't really care what happens after that.
My last 2 sentences are how I run projects. It's not Agile in any way, although Agile did claim some of those features as its own, eventually. Do recall Agile, when it started, promoted XP, essentially code for how to take 2 developers and quarter their output. It's gone through several redefinitions since then, and just because it touts some ideas I've been following for years prior to Agile's conception doesn't mean those ideas are "Agile".
Considering I've seen US Fed gov software development contracts pre-Agile and still think Agile is crap, I guess that proves you wrong. Granted, waterfall isn't great either, but therein lies another fallacy, for Agile people, it's waterfall or Agile, for everyone else, there common sense project planning which is in between those two.
That's not quite Agile - you need enough of a plan and a design to know WTF you're doing before you start, you just don't need an in-depth design of stuff you won't even touch for 6 months. But you know what the components are, and about how big each one will be, at least relative to each other, and you know where the dependencies are.
What you're describing is not listed in the Agile manifesto, and certainly not in the first few years of Agile crap. This is progressive project planning, and it existed decades prior to the Agile plague.
So how do you know ho long it will take? You measure you're progress! When you know you're 20% done, and it took a month, then you know it's a 5-month project.
That's utter crap, and you know it if you're any good at all. You have no way to measure it that accurately unless you're doing cookie-cutter code where the next 10% of features are just as hard as the previous 10%.
I've been within 5% on estimates for large projects, even as they changed significantly over the course of the project we could be that accurate on updated estimates.
Why weren't you 100% on target? After all, you updated estimates as you went. The better question is how close were you to the original estimate with allowances for the major changes along the way? I've been within 10% on a number of projects I was in control of. With a specific Agile project being run by a PM, a BA, and 2 stake holders we were about 500% off. Notice a problem there? Not a single technical person. Because Agile told them you didn't need a technical person running the project, and that costs would be contained, because, well, they were using Agile. They even had their Agile certificates hanging on the wall.
Agile is intended to get you to stop trying to jam a square peg in a round hole. The alternative is to pound on that bitch 'till it's round. Which one is likely to result in a better engineered end product?
Agile does NOT say "start coding and figure it out as we go." Agile says "Take some small subset of the functionality you've declared "the most important," estimate that, and deliver that."
So your version of Agile is create mini projects? Because no where does Agile say that mini-projects are part of the process. (One of the many failings of Agile is that no where does it really say anything meaningful) What you're describing is project planning, not Agile.
If you're a true Agile team, you're cross-functional, which means that proper representation from ALL of the organizations needed to deliver the product is present, embedded in your team.
Um, no, this only happens in organizations that are small enough that everyone's involved in 1 project. In the real world, I may have 100+ people working on a large project. There's no way everyone involved with all aspects are part of all teams. All they'd do all day is meetings, which, btw, is another one of the major failings of Agile, it leads to meeting paralysis.
While devs are banging out designs and code, Testers are working on test plans and test automation given the specs that the devs produce, and Support people are building operations documentation and support matrices etc. - all in parallel, all coordinating with one another as the process goes.
Agile is pretty much crap. You don't build a bridge that way, nor any other project, except maybe landscaping. If you have enough to sketch out a plan, you have enough to plan. You can't build something if you don't know what your target is.
When I have one of those... I just say - well, if it should stay the same, why don't we just change that one line back. There's no difference according to you.
0) It's hard to explain to people that they need encryption, how it works, what it is. People think email is secure! The "envelope" iconography is very misleading - email is more like a postcard, delivered by a random selection of disreputable postmen.
This is incorrect at this point, I'd say it's more like a postcard pinned to a bulletin board in the hallway, with everyone passing being required to take whatever cards are going to where they are going, with the requirement that multiple copies be made and dropped at every corner on the trek. That's probably more accurate as an analogy of today's email situation. The implication being, obviously, that email is visible to everyone on the trip, and copies are made and kept.
As for the rest, there are ways around a lot of that, but we're not there yet. Your analysis of webmail is spot on, webmail as it lives today should die a very very quick death. The sooner, the better.
While normally I'd say no, in this case, the only way this judge will see the light is to personally experience just exactly what it means to be hacked. He's already demonstrated a total lack of understanding with actual evidence thrown in front of him, so maybe the experience will enlighten him. Would his position be the same with the meth-addicted gun toting neighbor that shoots randomly into the neighborhood yesterday, that he's not an imminent threat today.... some people are just idiots.
It already happened to Sony, recall the CD rootkit incident? That was even more evil, as it wasn't just malware, but an actual attack. Sony's still around but they seem to be having some financial trouble of late or something. Karma sure can be a bitch.
JS failed on mobile....The browser has been evolving to reduce or eliminate the need for JS as much as possible.
When did either of those things happen? Wishful thinking?
You are serious? Your reading comprehension is that contemptible? Show me the wonderful set of JS apps for mobile. Anything in the top 100 for any of the 4 top smartphone OSes (yep, I'll even let you go down to Blackberry).
HTML5 - huge reduction in JS needs.
Oh, that[JS] failed a long time ago. Why people keep using it is beyond me. At least people learned to stop using it on mobile.
Because there's nothing better? At least CoffeeScript has fallen by the wayside.
Having been down the path of using JS on the server, I can unequivocally state "hell no". Debugging that crap is worse than debugging on a browser, where at least the toolset and use cases are somewhat limited. Try handling JS requests running against shared data. Oops, multi-threaded what? Node.js does not have a benefit with non-blocking IO, as that's been around in Java since Java6, and is now in its 3rd generation. It's unlikely JS will ever catch Java in performance, security, maintainability, nor just ease of use.
What's truly funny about your 1 sided viewpoint is that it's purely based on the browser. JS failed on mobile, completely, because it sucks so badly. The browser has been evolving to reduce or eliminate the need for JS as much as possible. (Have you even looked at HTML5?) New frameworks and "wrapping languages" keep popping up purporting to "fix JS", there's a hint, it's not because JS is great. So far everything has failed with the possible exception of jQuery, which actually has lasted and remained somewhat useful, primarily because it's a toolset that reduces the JS disaster to something manageable.
...Optimal Java runs only 3 times slower as C code...
Where on earth do you get this info? Java, depending upon the usage, can run faster than equivalent C code. If you're talking about micro-benchmarks, then I'd agree. Generally speaking, I don't write micro-benchmark type code.
I agree with the rest of your sentiments however.
This is a pipe dream of someone, somewhere, that continues to want to control something they're selling to others. Somehow it seems they are violating the Doctrine of First Sale, IMHO,
Slashdot Mirror
The blueprints is the requirements and planning stage, with API definitions. This does involve iterations. Coding is the building process, where checks (testing) validate the components before the next layer is added.
I design and build a data store, complete with an API in between. (the Foundation) It was designed with certain requirements in mind, because performance is a key metric I'm going to be measured on when it's done. Some Agile moron comes along 6 months later, and decides that he needs to filter with permissions in a new way that the DB was not designed for which works with today's traffic. Ideally this change requires a new foundation, because now, instead of an arch bridge, we're building a suspension bridge. The foundation requirements changed, and if we were doing it right, we'd tear everything down, but in the agile world we just slap some extra code (mortar) on the foundation, and voila, it runs/stands. Then traffic doubles, and the bridge fails.
You will pay the piper, sooner or later. Agile advocates later, which is why it's so popular with business types. That's fine if you never plan on being anywhere longer than a year or two, and don't really care what happens after that.
My last 2 sentences are how I run projects. It's not Agile in any way, although Agile did claim some of those features as its own, eventually. Do recall Agile, when it started, promoted XP, essentially code for how to take 2 developers and quarter their output. It's gone through several redefinitions since then, and just because it touts some ideas I've been following for years prior to Agile's conception doesn't mean those ideas are "Agile".
Considering I've seen US Fed gov software development contracts pre-Agile and still think Agile is crap, I guess that proves you wrong. Granted, waterfall isn't great either, but therein lies another fallacy, for Agile people, it's waterfall or Agile, for everyone else, there common sense project planning which is in between those two.
That's not quite Agile - you need enough of a plan and a design to know WTF you're doing before you start, you just don't need an in-depth design of stuff you won't even touch for 6 months. But you know what the components are, and about how big each one will be, at least relative to each other, and you know where the dependencies are.
What you're describing is not listed in the Agile manifesto, and certainly not in the first few years of Agile crap. This is progressive project planning, and it existed decades prior to the Agile plague.
So how do you know ho long it will take? You measure you're progress! When you know you're 20% done, and it took a month, then you know it's a 5-month project.
That's utter crap, and you know it if you're any good at all. You have no way to measure it that accurately unless you're doing cookie-cutter code where the next 10% of features are just as hard as the previous 10%.
I've been within 5% on estimates for large projects, even as they changed significantly over the course of the project we could be that accurate on updated estimates.
Why weren't you 100% on target? After all, you updated estimates as you went. The better question is how close were you to the original estimate with allowances for the major changes along the way? I've been within 10% on a number of projects I was in control of. With a specific Agile project being run by a PM, a BA, and 2 stake holders we were about 500% off. Notice a problem there? Not a single technical person. Because Agile told them you didn't need a technical person running the project, and that costs would be contained, because, well, they were using Agile. They even had their Agile certificates hanging on the wall.
Agile is intended to get you to stop trying to jam a square peg in a round hole. The alternative is to pound on that bitch 'till it's round. Which one is likely to result in a better engineered end product?
If I need a round peg....
Agile does NOT say "start coding and figure it out as we go." Agile says "Take some small subset of the functionality you've declared "the most important," estimate that, and deliver that."
So your version of Agile is create mini projects? Because no where does Agile say that mini-projects are part of the process. (One of the many failings of Agile is that no where does it really say anything meaningful) What you're describing is project planning, not Agile.
If you're a true Agile team, you're cross-functional, which means that proper representation from ALL of the organizations needed to deliver the product is present, embedded in your team.
Um, no, this only happens in organizations that are small enough that everyone's involved in 1 project. In the real world, I may have 100+ people working on a large project. There's no way everyone involved with all aspects are part of all teams. All they'd do all day is meetings, which, btw, is another one of the major failings of Agile, it leads to meeting paralysis.
While devs are banging out designs and code, Testers are working on test plans and test automation given the specs that the devs produce, and Support people are building operations documentation and support matrices etc. - all in parallel, all coordinating with one another as the process goes.
That's a nice fairy tale.
Agile is pretty much crap. You don't build a bridge that way, nor any other project, except maybe landscaping. If you have enough to sketch out a plan, you have enough to plan. You can't build something if you don't know what your target is.
When I have one of those... I just say - well, if it should stay the same, why don't we just change that one line back. There's no difference according to you.
Or a District 9 sequel.
I'd rather go to a roll my own model for everyone. I do it now....
0) It's hard to explain to people that they need encryption, how it works, what it is. People think email is secure! The "envelope" iconography is very misleading - email is more like a postcard, delivered by a random selection of disreputable postmen.
This is incorrect at this point, I'd say it's more like a postcard pinned to a bulletin board in the hallway, with everyone passing being required to take whatever cards are going to where they are going, with the requirement that multiple copies be made and dropped at every corner on the trek. That's probably more accurate as an analogy of today's email situation. The implication being, obviously, that email is visible to everyone on the trip, and copies are made and kept.
As for the rest, there are ways around a lot of that, but we're not there yet. Your analysis of webmail is spot on, webmail as it lives today should die a very very quick death. The sooner, the better.
While normally I'd say no, in this case, the only way this judge will see the light is to personally experience just exactly what it means to be hacked. He's already demonstrated a total lack of understanding with actual evidence thrown in front of him, so maybe the experience will enlighten him. Would his position be the same with the meth-addicted gun toting neighbor that shoots randomly into the neighborhood yesterday, that he's not an imminent threat today.... some people are just idiots.
Maybe ask the government to grant snowden clemency?
Nah. Why exert the effort to click an online petition when it is so much easier to just bitch about how hopeless things are?
And yet you post as AC.....
It already happened to Sony, recall the CD rootkit incident? That was even more evil, as it wasn't just malware, but an actual attack. Sony's still around but they seem to be having some financial trouble of late or something. Karma sure can be a bitch.
JS failed on mobile....The browser has been evolving to reduce or eliminate the need for JS as much as possible.
When did either of those things happen? Wishful thinking?
You are serious? Your reading comprehension is that contemptible? Show me the wonderful set of JS apps for mobile. Anything in the top 100 for any of the 4 top smartphone OSes (yep, I'll even let you go down to Blackberry).
HTML5 - huge reduction in JS needs.
Oh, that[JS] failed a long time ago. Why people keep using it is beyond me. At least people learned to stop using it on mobile.
Because there's nothing better? At least CoffeeScript has fallen by the wayside.
Having been down the path of using JS on the server, I can unequivocally state "hell no". Debugging that crap is worse than debugging on a browser, where at least the toolset and use cases are somewhat limited. Try handling JS requests running against shared data. Oops, multi-threaded what? Node.js does not have a benefit with non-blocking IO, as that's been around in Java since Java6, and is now in its 3rd generation. It's unlikely JS will ever catch Java in performance, security, maintainability, nor just ease of use.
What's truly funny about your 1 sided viewpoint is that it's purely based on the browser. JS failed on mobile, completely, because it sucks so badly. The browser has been evolving to reduce or eliminate the need for JS as much as possible. (Have you even looked at HTML5?) New frameworks and "wrapping languages" keep popping up purporting to "fix JS", there's a hint, it's not because JS is great. So far everything has failed with the possible exception of jQuery, which actually has lasted and remained somewhat useful, primarily because it's a toolset that reduces the JS disaster to something manageable.
...Optimal Java runs only 3 times slower as C code...
Where on earth do you get this info? Java, depending upon the usage, can run faster than equivalent C code. If you're talking about micro-benchmarks, then I'd agree. Generally speaking, I don't write micro-benchmark type code. I agree with the rest of your sentiments however.
yah, but we trust google more than AT&T.
Out of the mouths of babes...
sometimes only comes prattling nonsense.
some random node anywhere....
USA - and first sale allows you to resell or otherwise do what you want with a copyrighted work, ie, right to distribute.
Disney already dumped millions into John Carter....
This is a pipe dream of someone, somewhere, that continues to want to control something they're selling to others. Somehow it seems they are violating the Doctrine of First Sale, IMHO,
Seems silly as my CPU runs inside a grounded metal box.
What we can say is bad is refined sugar, high fructose corn syrup, and other manufactured/highly processed foods.
A browser is significantly more capable than ms word even if it began with humble origins.
I'm not sure about that, granted this is excel, although Word has it share of fun and games too.