Why Do Web Developers Keep Making The Same Mistakes? (hpe.com) 335
An anonymous reader quotes HPE Insights:
Software developers and testers must be sick of hearing security nuts rant, "Beware SQL injection! Monitor for cross-site scripting! Watch for hijacked session credentials!" I suspect the developers tune us out... The industry has generated newer tools, better testing suites, Agile methodologies, and other advances in writing and testing software. Despite all that, coders keep making the same dumb mistakes, peer reviews keep missing those mistakes, test tools fail to catch those mistakes, and hackers keep finding ways to exploit those mistakes. One way to see the repeat offenders is to look at the Open Web Application Security Project Top 10, a sometimes controversial ranking of the 10 primary vulnerabilities, published every three or four years by the Open Web Application Security Project... It boggles the mind that a majority of top 10 issues appear across the 2007, 2010, 2013, and draft 2017 OWASP lists...
It's sad that eight out of 10 of the issues from 2013 are still top security issues in 2017. In fact, if you consider that the draft 2017 list combined two of the 2013 items, it's actually nine out of 10. Ouch... What can you do? Train everyone better, for starters. Look at coding and test tools that can help detect or prevent security vulnerabilities, but don't consider them silver bullets. Do dynamic application security testing, including penetration testing and fuzz testing. Ensure admins do their part to protect applications. And finally, make sure you establish a culture of security-aware programming and deployment.
It's sad that eight out of 10 of the issues from 2013 are still top security issues in 2017. In fact, if you consider that the draft 2017 list combined two of the 2013 items, it's actually nine out of 10. Ouch... What can you do? Train everyone better, for starters. Look at coding and test tools that can help detect or prevent security vulnerabilities, but don't consider them silver bullets. Do dynamic application security testing, including penetration testing and fuzz testing. Ensure admins do their part to protect applications. And finally, make sure you establish a culture of security-aware programming and deployment.
Wrong (Score:5, Insightful)
Re:Wrong (Score:5, Insightful)
That's not the same web devs making those same mistakes. Developers with some experience do not write code that fails against easy sql-injection. But companies prefer to hire younger inexperienced devs for the reasons that have been discussed here on /. many times.
I'll add to that that this isn't limited to web developers.
Re:Wrong (Score:4, Insightful)
I'll add to that that this isn't limited to web developers.
Hell yeah this. In most fields, there's decades of prior wisdom that one should at least try to get a grasp of before making "brilliant" inventions. Like, you shouldn't write an init system before reading "Unix for Dummies".
Things like SIGHUP/nohup are basic knowledge, if you don't know this you shouldn't write your snowflake way of killing processes on logout. If you don't know ways to authenticate users and what user names are explicitly allowed by POSIX (the 0day issue), you shouldn't create a gaping security hole, and even worse, you don't WONTFIX it just because one of your distribution's clicky-clicky tools doesn't allow such names, while "$EDITOR /etc/passwd" or LDAP are "user errors".
I'm for one a kernel newbie -- yet I know better than when faced with a problem like "shit network driver does high-order allocations while atomic, with disastrous reasons when under memory pressure" to rush into making an ad-hoc pool instead of reading how it should be done, or asking those with a clue. The former was my first reaction, yet I at least bothered to think before wasting developers' time with a bogus patch.
Re: (Score:3)
Hell yeah this. In most fields, there's decades of prior wisdom that one should at least try to get a grasp of before making "brilliant" inventions. Like, you shouldn't write an init system before reading "Unix for Dummies".
Obligatory reference [youtu.be]
Re:Wrong (Score:5, Insightful)
Does not match my experience. Some (few, say 10%) of these people do indeed acquire insight and experience with more time in the field, but most do not seem to. They make the same basic mistakes and have the same defective and incomplete understanding of how thing work, 5 years in, 10 years in and then they move to another field because they have become unemployable in their "specialty".
Comment removed (Score:5, Funny)
Re: (Score:3, Insightful)
Those few are the ones you want to keep. However, you won't be able to keep them if you don't pay them well, or make their lives difficult/annoying with stupid management decisions. They'll be the first to leave as they have many options and don't have to deal with stupidity -- leaving your company with those that seem unable to learn from their mistakes, or just don't give a shit.
I'm considered a decent developer, and if you want to keep me you better be prepared to pay me significantly more than that fr
Re: (Score:2)
Yes, very much so. I see that all the time, especially with large customers.
Re: (Score:2)
Well yeah, because most are web developers; very few are web developers AND security experts at the same time, and they are usually way more expensive.
Code written by web developers must go through a security audit and insecure parts need to be rewritten to close the security holes.
Re: (Score:2)
Code written by web developers must go through a security audit and insecure parts need to be rewritten to close the security holes.
I think *all* code should go through at least peer review by a senior team member. It is the flamboyant prima donna who thinks they are above the rest of the team make the biggest blunders.
Re: (Score:2)
Tell me about it. I am a security expert and sometimes do coding for customers. For one large customer, I do cost about 2.5 times per hour than their regular coders. On the other hand, I think that their regular coders are directly more expensive and the time they need to do things (than then suck afterwards) is really impressive. I have seen quotes like $500k just for changing the path in a web-application and placing a proxy in front of it. Incredible.
True. We teach problems instead of solutions (Score:3)
My experience is the same, most (but not all) experienced people are people who have been doing the same stupid shit for a long time. Some people put in the effort to learn something new and improve every week. Most people don't.
For those who DO try to constantly learn and improve, the security community has made a mistake in how we try to help them. The OWASP top 10 list was mentioned. I'm a member of OWASP. The list, which we promote, is a basically list of how bad guys can exploit vulnerabilities.
Re: (Score:3)
I must have been exceptionally lucky to work for an employer who also understood the importance of having a solid team of testers working closely with the developers.
For a start we had to make sure that nothing a user could type into a text entry could break the web page or the database, either on the way in or when coming back out to be displayed, be it the most basic issues like apostrophes in user names or HTML tags and such.
Then the testers had to learn all sorts of clever tricks to get around our best
Re: (Score:3)
That's not the same web devs making those same mistakes.
True, the web developers from 2013 have all retired and taken up jobs in the fast food industry by now.
Re: (Score:3)
Well that pretty much applies to practically every job these days. The companies pursue money above all else, to the detriment of themselves - assuming everyone (and everything) is a swappable interchangeable part.
Nothing can be further from the t
Re:Wrong (Score:5, Insightful)
If these errors keep occurring, you have to stop blaming the web developers and start blaming the technology. There is no good reason that cross-site scripting or session hacking should even be possible. It's a mad idea to turn user input into a human-readable SQL command string when no human needs to read it.
The problem is that we stared off with insecure shoddy hacks and there has been a whole slew of incremental mitigations, none of which happens by default in order not to break further the already-broken crap that's out there. That's not the fault of the application developers, that's the fault of the browser and server developers.
Re: (Score:3)
This was my thought too - if you have a critical component in a system, you want to make it as difficult as possible to get wrong.
Especially if there is clearly a "correct" and "incorrect" way to do something. There's a reason most sane cables either make it extremely difficult to connect in the wrong orientation or even better make it so all the likely orientations are serviceable.
The tools and frameworks could pick up the ball and make it more difficult to get things wrong, this would be much less an iss
Re: (Score:2)
Re: (Score:3)
The mistakes are possible because they aren't always mistakes.
How do you prevent SQL injection? Putting user input into other strings is a reasonable thing to do. Passing a string to the database is a reasonable thing to do. It would be a pain to use parameterized SQL for everything, and I don't know of a database that does.
There's ways to sanitize a user-entered string so it can't be used for cross-site scripting. Make that mandatory for using user-entered strings and you'll break some other stuff
Re: (Score:2)
That's not the same web devs making those same mistakes. Developers with some experience do not write code that fails against easy sql-injection. But companies prefer to hire younger inexperienced devs for the reasons that have been discussed here on /. many times.
Yes, companies tend to search the bargain bin for unicorns even though it's completely irrational. Either they go with young inexperienced recent college grads or they go with H1B's. The headline ought to read "Why do companies keep making the same mistakes hiring recent college grads and H1B Visa's resulting in poor software quality instead of hiring talented, experienced developers who can write quality code?"
The answer to this question is simple: Companies have champagne taste and a beer budget.
Nothi
Re: (Score:2)
Re: (Score:2)
I wouldn't be too sure. A few dozen programmers that program that way, and possibly even teach how to program that way, could fill the web with thousands upon thousands of these common mistakes.
Security is always last (Score:5, Insightful)
Security is always last when implementing a new piece of software. Until management gets that security is vital to their well being, this will continue to happen. But since they have cybersecurity insurance and since everyone has the memory of a goldfish, the company will be fine, and therefore they don't need to spend the money on it. After all it would just be an added expense and possibly delay the introduction of the software in the first place which could ultimately be worse than having a buggy program.
Re: (Score:2)
The traditional life-cycle of a company has it being taken over by accountants just before it dies. Because accountants have real problems putting numbers to intangibles - like security. The developer hours required to implement security? *That* they can put a number to ... in the expense column. So, basically, as an expense with no immediate benefit, security gets the short end of the stick ... if it even gets that much. The situation gets worse when 'security' becomes another department. Then the g
Re: (Score:2)
Because you keep replacing them with kids. (Score:2)
Next question.
Simple: Cheaper than possible personnel (Score:5, Informative)
Web application developers are the lowest-skilled, least educated and least talented people in the IT space. I recently had to explain to some people with supposedly 5 years experience in that space what an HTTP header looks like, because they had no clue. Same for basically every other aspect, like cookie naming, how to make you application able to work behind a proxy (in an enterprise-environment, no less), etc. It is staggering how clueless these people are. All they seem to see is a framework, which they barely understand and then put an application on top that makes all the basic mistakes you can think of. Of course, they eventually remove the mistakes that break the application in the specific target environment for a specific browser, but that is it. Forget about any understanding of the mechanisms they are using or of IT security. Some do not even know what an IP address is or how an URL is composed from components.
So in essence: Developers that are grossly incompetent and management that is grossly incompetent for hiring these people. As we have a lot of "bean-copunter" types in management these days (MBAs and even less competent ones), things will not change anytime soon.
Re: (Score:2)
Yes, there is plenty of blame to go around. Part of that blame is on CS depts. I was once associated with a CS dept. of a major midwest uni. They said they had an "honors" group of students. I got saddled with three of them for a project in Java. When I asked if they could whack together something that did X, they grumbled, moaned, whined, and produced nothing. They didn't know how to get started. Yet they all went on to "promising" careers in industry...and they were seniors.
The real problems are... (Score:5, Insightful)
IMHO, these problems stem from the following source problems:
- Incompetent developers. Look at the number one problem, number one for years now: injection. I teach students how to avoid this the first time they touch a database, which is typically in year two of their degree program. It doesn't matter: half of them still write injectable queries, even though using "prepared statements" isn't any more complex. The thing is: there is so much code to be written, that even these students - who evidently don't understand, don't care, and can't be bothered - even these students will find jobs, and some of them will be working on your web projects.
- Internet speed. TFA talks about "agile methodologies" as if they were a good thing. While "iterative development" absolutely does make sense, in too many companies "agile", and "Scrum" and their brethren are an excuse for pushing half-tested code out the door, because everything has to be fast, fast, fast . I have news for the marketing department: No, your latest brainstorm does not have to be live next week. In fact, given that the brainstorm-after-next will basically reverse this one, it would really be better for everyone if you just fell off a bridge and drowned.
- Too many frameworks. Real example: I used to use Guice, a small dependency-injection framework from Google, for a small demo-project. A few months ago I decided to update Guice to the latest version. But the latest version depends on another framework, Guava. Guava requires JavaX. JavaX requires Spring. Spring requires...good god, at this point I deleted Guice. I mean, seriously, binding in that much foreign code? First, you are now dependent on all that code, and whatever changes are made to it. Second, you are bringing in all of the vulnerabilties present in that code. And you have absolutely no idea what those may be, because you certainly aren't going to validate all of that code yourself. Thank you very much, I'll just implement that small bit of functionality I need, all by myself.
Re: (Score:3, Funny)
Look on the bright side, it didn't need systemd or gnome.
Re: (Score:3)
I fully agree on all of these. I also teach a software security lecture, and last year one student summarized the purpose as "warn everybody to get an expert and not to do it themselves". Well, at least that one learned something.
As to the last point: This is a real catastrophe in the making. Nobody still understand what they do and their dependencies seem to grow all the time. I now push "does not depend on frameworks" as a sign of quality to customers, wherever possible.
Re: (Score:2)
Quality? That's not quality. *OUR* software comes with its own Kernel, or are you gonna deny that Kernels aren't full of security issues? Some kernels consists of over 15 million lines of code! Did you check all those?
Sure, customers are surprised at first when none of their other software runs anymore on machines with ours installed, but it is guaranteed secure.
Re: (Score:2)
Who let the clown in?
Re: (Score:2)
I would very much like to know what the first day in your course is like.
I think you have to honestly look at yourself and if you are not educating developers on how and why injection flaws work, and how they must be stopped at every handoff of data between interpretatio
Re: (Score:2)
Ah, yes. "Bouncing Betty" (or "Galloping Gertie"), the Tacoma Narrows Bridge. I saw a picture in my Software Engineering course. Do you have a source of the video that is not YouTube? I should indeed show that to my students as a reminder that they will be engineers and that engineering failure can kill.
My first lecture starts stating that almost every piece of software these days is connected to the Internet in some way. Then it gives a broad overview over the things that can go wrong. I will treat them in
Re: (Score:2)
Re: (Score:2)
Well, an 800M Euro firework is kind of impressive on its own.
Re: (Score:2)
Well, one additional problem is that selecting a framework is not easy to do and you only find out after having worked with it for some time what it is good at and were it sucks. And long-term support is always dicey. By KISS, if you can reasonably do it without a framework, then do so. Of course, if things get vastly more complicated because of all the things you need to re-invent, that is a different situation.
Re: (Score:2)
Too many frameworks... that's a good one. You're worried about the vulnerabilities in some of the most stable, highly scrutinized, fully unit tested and secure frameworks Java has on offer and because of that... you roll your own.
I guess I know what is really wrong with the industry: developers that think they can create their own framework, replacing several dozen man years of coding, debugging and testing in just a few days -- and then having the arrogance to think it will contain less vulnerabilities ri
Re: (Score:3)
I think there’s a side issue: only by trying to write one’s own, does one start to understand the problem. So as a learning excercise, trying to write one’s own is really useful. And then, use a proper framework. Otherwise there’s the opposite problem of people relying on frameworks which they don’t understand.
Re: (Score:2)
Depend on the amount of code from the framework you actually need. If you're bringing in half a million lines of code to do something that could be done in a couple of thousand, then you're probably better off rolling your own: it's going to have far more tightly coupled logic and be more amenable to static analysis, as well as being an easier target to fuzz test.
If, on the other hand, you end up implementing most of the logic in a dependency, then you're probably better off using the one that's widely
Re: (Score:2)
You're worried about the vulnerabilities in some of the most stable, highly scrutinized, fully unit tested and secure frameworks Java has on offer and because of that... you roll your own.
Because a random huge piece of code is likely to be bug-free?
Re: (Score:2)
For a random piece of code, I don't know.
However, we weren't talking about a random piece of code, but some of the most used frameworks (in any language) on the planet.
What do you think is a more likely source of security bugs?
a) Closed source code written by your team / company, used by only your team and maybe a few others in the company, with a small end-user base (a few hundred thousand) in a maybe half a dozen apps or websites?
b) Open source framework code, with regular releases used by millions of dev
Re: (Score:2)
You can also have fully unit tested code, and as soon as you start integrating it into another system, things fall apart.
Integration testing is much much harder than unit testing.
Re:The real problems are... (Score:4, Informative)
The example given was Guice, which is a DI framework. To implement DI you need to write at least a couple of thousand lines of code, using not every day concepts like annotation scanning, reflection, thread safety, etc. That's a non-trivial amount of work requiring a solid test suite to boot.
Other than that I totally agree with you. I cringe every time I see some huge framework imported just to use one of its utility functions... Sure, a framework is great if over half the code needs it and it saves a lot of work, but adding a new huge framework to a huge existing code base without thought to save writing a dozen lines of code? I reject those commits when I'm leading the project.
Re: (Score:2)
To implement DI you need to write at least a couple of thousand lines of code, using not every day concepts like annotation scanning, reflection, thread safety, etc.
Hahahaha
Java
Oh, fuck. Well, here you may have your problem.
Re: (Score:2)
Oh, another one of those "the language is your problem" people.
I suppose you also say stuff like:
"... if we had written it in X using this 3 month old framework then we wouldn't be in this mess."
"You don't need a compiler, just write unit tests with full coverage."
"... in language X you can write 30% less lines of code, resulting in 30% less mistakes!"
"My programming speed is bottlenecked by the amount of characters I need to type..."
Anyway, thanks I'll give your valuable opinion the attention it deserves.
Re: (Score:2)
I wrote a simple DI framework, it does take a bit more than that for even basic functionality. However, I'm interested so if you have some link or code. Perhaps it will offer some inspiration.
I would have used an existing framework, but none of the ones I found supported changing dependencies at runtime (when loading a plugin or something). Both Guice and Spring are very much static
Re: (Score:3)
The thing is: there is so much code to be written, that even these students - who evidently don't understand, don't care, and can't be bothered - even these students will find jobs, and some of them will be working on your web projects.
And some of them will be working for PHBs that don't understand, don't care and can't be bothered. Far too often the only metric people are measured by is whether the code does the right thing with the right input under normal execution. Error handling? Security? It's working, ship it. That's what you get measured on. That's what your boss gets measured on. If you say it "isn't any more complex" and they do it anyway it's clearly because they don't get corrected or rejected. Those errors conditions are for
Re: (Score:2)
Too many frameworks.
The problem is more commonly one too few frameworks: specifically, people going above their pay grade and reinventing the CMS. Then they get the opportunity to make all those errors. If people just begin with a working CMS, they get to make a whole different class of mistake instead :)
Re: The real problems are... (Score:2)
Because Word Press is so much more secure than an in house CMS.
Re: (Score:2)
Because the market doesn't value security. (Score:3)
The pressure to release early and often is extreme. "MVP" rules the day, and no one in most senior roles has the granular perspective necessary to be aware of "security" as a concept. Is it checked into the testing repo and does it run? PUSH IT OUT. We'll fix any bugs as we "iterate."
Oh wait, we won't actually iterate. Because existing features don't get us as much as releases of new ones. We'll just keep pushing out new ones as fast as we can.
Security? Hell, often even basic functionality doesn't work. Release it broken, then declare it that part code deprecated in favor of new versions with new features in six months. Even if security is flawed, that's okay, it was only out for a few months "that way." Anyone still using it should have upgraded. If they don't it's their fault.
There are flaws in the new version/new features as well? Well they've only been out for eight weeks. It was an MVP. We're agile. We'll fix any bugs as we "iterate..."
etc.
Re: (Score:2)
Frameworks and CMS's (Score:2)
I think that most frameworks and CMS's don't provide the right security that is needed to create a secure website. They offer protection against SQL injection, XSS and other common attacks, but don't provide a means for developers to make sure they used it correctly. Look at all the Wordpress plugins that keep on being vulnerable. How do you know a plugin is secure or not? In my opinion, there is a big difference between secure code and provable secure code. So, it's not only web developers making the same
Budgets (Score:2)
There is room in budgets to pay attention to some good practices or enforcement thereof by peer review. But often - especially with custom-made sites - it is simply not enough. I've seen plenty of projects where the design company was granted bigger fees for more hours than implementation, stereotypically also making everyone overly complicated. Even during scrum sessions where developer input is more present, doing it quickly is a much larger focus than doing it right. In the end, that simply leads to slop
Re: (Score:3)
"scrum sessions" There's your problem right there. Agile does not encourage good overall design. It is a micromanagering dream and causes coders to only work for the next sprint goals. As long as their little piece of the pie works, they get rewarded. The entire dirty snowball that gets produced is merely a by-product.
Re: (Score:2)
Re: (Score:2)
Ob (Score:2)
27 people have already pointed out that web devs are fucktards, so I won't. Remember that they took something designed for displaying static pages and shoehorned interaction & dynamic shit onto it. The whole thing is built on sand.
Re: (Score:2)
Re: (Score:2)
Some parts of C++ need more than 32K (Score:3)
Unless you're targeting a system with 32KB of RAM or less, or you have very strict realtime guarantees (and so aren't even using malloc) there's rarely a good reason to use C these days.
I would dispute this 32 KiB figure.
Several years ago, I wrote a program for Game Boy Advance homebrew that used a single std::ostringstream once, and even after enabling -Wl,--gc-sections, the statically linked executable was 180,032 bytes. It turned out that the constructor for a std::ostringstream in GNU libstdc++ would call the constructors for date, time, and currency formatting aspects of the locale even if I never output a date, time, or currency object. For a scale reference, the GBA's RAM is 32 KiB
Re: (Score:2)
The problem with C is that the unsafe stuff is default. Some of this was fixed over time, but it's taken so long that the unsafe practices are prevalent. Some of the functions later meant to offset this issue are sometimes not found in stock compilers (even if there's an update that later adds them.)
Oh, and I did find a useful feature in one of the compilers. Turns out it was just specific to that one, and I had to rewrite code since it wasn't standard.
Email addresses! (Score:2)
Learn how to properly parse an email address!!!
It's upsetting how many web sites tell me a valid email address is invalid because the developers don't use a library that parses it correctly and don't bother looking up what is actually valid. Apostrophes and pluses are the main characters they get wrong, among others.
Re: (Score:3)
Actually, most libraries are wrong, too. If you look at nodejs, it's astonishing how 90% of packages that ship a single line of code (plus tons of boilerplate) get even that single line wrong.
It doesn't take a genius to look up the relevant RFC and write a regexp.
Re: (Score:2)
Getting such a regex right is MUCH harder than it looks:
https://stackoverflow.com/ques... [stackoverflow.com]
Rgds
Damon
Re: (Score:2)
Depends on whether you want to support pre-Internet addresses, as that's a good part of the spec. If you drop stuff like routed addresses or comments/whitespace inside a domain, the rest is quite simple. Your MTA likely won't accept "@node.test:mary@ (this is a comment) example (whitespace around .) .net" thus it should be dropped at validation time.
Re: (Score:2)
I hear you. (I used to run a significant UUCP mail node, BTW!)
But then we have to agree on a definition of 'right' for the application, which is nuanced.
I still have a perfectly valid address rejected sometimes because it's 'too short'! (It's of the form X@YY.ZZZ)
Rgds
Damon
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Email addresses either work or not (that's what the verification mail is for). Why software bothers to "parse" these at all I never quite understood -- there is nothing to parse, nothing to extract, it is a piece of text that when fed to an SMTP program may or may not result in a mail to whoever is filling in your form.
If I want to give you a wrong email address there is nothing you can do about it anyway. If you want to be sure, you send a verification mail, no parsing needed. The mail either works or n
Why? (Score:2)
"Why Do Web Developers Keep Making The Same Mistakes?"
StackOverflow.com
(they read the same wrong answers as other people, because every "I found this useful" or "Lots of people read this" ranking system does not detect factual errors, only opinions)
Re: (Score:2)
Came looking for this, was not disappointed. They keep finding the same broken half-answers on a web site that is skewed by people scamming for points.
I never signed up for SO, and now it's not worth bothering, because between so much already having been answered, and people who know less than they think they do down-voting good answers, I could never get any kind of decent reputation score, short of creating my own programming language that got popular so I'd have fresh questions to answer.
Re: (Score:2)
Re: (Score:2)
Software is difficult (Score:2)
Even the simplests of software consists of thousands of lines of code where a simple mistake can compromise the system. People make mistakes. Online documentation gives flawed examples. It will take an infinite amount of time to write software to perfection. The poor guy in India working 80 hours per week coding the system has no way to know every system he is writing code for. Nobody has ever told the entry level developer that the secure_rng() or mysql_escape_string() library function is in fact not secu
Re: (Score:2)
Every year (Score:2)
my students make the same mistakes. It is as if they learn nothing...
quick and dirty (Score:2)
can it be that often times "Beware SQL injection! ..." is followed by "and I need it yesterday"?
Simple. Shiny (Score:2)
Web developers are more interested in showing off the latest and greatest procedures, bouncing ads and every unnecessary script they can lay their hands on than they are producing a usable web page.
Within the last week I am suddenly unable to access the comments section on a web page I have gone to for years. Most likely because the developers changed twenty scripts and since I never run the latest and greatest browser, comments are now inaccessible.
There is absolutely no reason not to have a link work in
Ctrl-C Ctrl-V (Score:4, Interesting)
Many APIs have demo code in curl or Java with the express warning that it's demo code and not to be used in production. But it shows up anyway.
I worked on a project last year where some offshore developers were tasked with writing an integration to a RESTful API for Nexpose. As far as "web programming" goes, talking to a REST API is pretty much a sine qua non for being called a "web developer". They didn't know how to do so. I understand that members of this same team have worked on other corporate sites.
Combine CTRL-C/CTRL-V with inexperience and you have the source of your mistakes.
Software "Engineering" vs Civil Engineering (Score:2)
I've been thinking about this for a few years and have come to the conclusion that we will continue making the same mistakes until we can create a set of rules that everyone can follow. If you look at what civil engineers have done you will see that they have reduced much of what they do to equations and repeatable patterns (for lack of a better term). When someone sets out to build a bridge or a building, they start by designing it with an architect and then they pull out the equations and key tables to
Why do web devs keep reinventing the CMS? (Score:2)
People keep thinking they can do better by themselves than whole teams of coders hammering on code and getting patches from dozens or hundreds more users, and they keep getting proven wrong. Why would anyone reinvent the CMS at this point?
Re: (Score:2)
Not invented here (Score:2)
Lots of interesting comments but didn't see this one so though I'd throw it in: Not Invented Here Syndrome.
I've seen this first hand a lot. Manny developers will get a project, review some options for components (e.g. CMS is the classic one) and decide that because that component only needs 99% of requirements, they should roll their own solution, because using that component and modifying it will take to long as they have to learn the extension system or whatever.
As a result they end up writing lots of new
Agile (Score:4, Interesting)
Indeed (Score:2)
my theory: (Score:2)
Really? (Score:3)
"Why do drivers keep making the same mistakes? It looks like eight of the top ten causes of death on the highway are the same as they were in 2013."
Um because this shit is difficult, and if you don't know anything about it, it's easy to ask vapid generalized questions that seem meaningful.
Part of the problem is our process (Score:3)
Re: (Score:2)
Apparently to some, it is not. These may be the people at the core of the problem, though.
Re: (Score:2)
Re: (Score:2)
The real mistake is that people think you can teach people how to write proper software with a couple of hundred contact hours as a small part of a 4 year university program. Many of these people didn't have enough prior interest in building software to even have tried writing some software before attending these classes.
It is about as delusional as thinking that you can become a star athlete having done nothing but sitting on a couch for years eating chips and then doing 4 years of aerobics and spinning c
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If you are a developer, with the current market, show some backbone and tell them they can do it themselves if they think they can do it quicker.
But I guess it all depends on the way your job market is structured. Apparently in some countries the reason you were fired or left the previous company is somehow considered relevant, and a good recommendation from your previous boss is mandatory if you ever want to work in the industry again. Experience is less relev
Re: (Score:2)