Programmers are complicating the Web culture

[jedishrfu]

Interesting article on the HackerNoon website:

A couple of weeks ago, I received Anselm’s newsletter, and I couldn’t agree more with Jeffrey’s article on his arguments regarding complexity. While reading his article, I confirmed my own beliefs and concerns about the future of web development. This is also what triggered these thoughts, and why I wanted to share my side of the story about this so called “cult of the complex”.

Dream team != (is not equal to) success
I keep seeing companies bringing unnecessary complexities in web development, for the simple reason of following the standard “corporate” hierarchy team-structure. I now experienced in person how a company can be brought up to keep such focus on the old fashioned standards, while leaving the coding environment to be poorly built. It made me wonder how much value they brought into building a “dream” team in a company, while completely ignoring the importance of advancing developments in areas such as the Internet and its technologies.

Read more here:

https://hackernoon.com/programmers-are-complicating-the-web-culture-b644dbeb6a21

 

[Bystander]

You don't seriously think that people are going to work themselves "out of jobs?" Do you?

 

[Tom.G]

You don't seriously think that people are going to work themselves "out of jobs?" Do you?

Sure! I did it regularly. It is called "Consulting." Lots of freedom and variety, little boredom, lots of free time for stuff other than "work."

RECOMMENDED!

 

[Stephen Tashi]

Is the main topic about complexity in how web pages function or is it about complexity in the process of how humans compose the web pages?

Why are some commercial web sites such as Amazon, and to some extent Ebay, so much more sophisticated that the websites of companies that also have large financial resources such as Home Depot and Walmart? Is this a conscious choice by some retailers not to have sophisticated websites? Or do they want to equal the sophistication of Amazon and just can't figure out how it's done?

 

[DavidSnider]

These articles are mainly complaining about how ridiculously complicated the web development tool chain has become.

"What's bower?"
"A package manager, install it with npm."
"What's npm?"
"A package manager, you can install it with brew"
"What's brew?"

 

[QuantumQuest]

I see various good points made in the article like

A company driven foremost by their financial successes, goals, deadlines, and building a cult of the complex

We need to continuously find ways that fit the product’s best needs, and keep adapting to these changes. We have to start building less complicated cults and focus on what matters the most.

Never get locked to one single web culture or “micro” ecosystem

Also, about inefficient workflows and finally about following the standards and trying to understand how everything works, as the best thing a developer can do.

From a theoretical standpoint, I couldn't agree more to these points but they express a purely idealized world which cannot exist. I think that, more or less, all of us working or doing business in the web, have at some point(s) think about ways to eliminate complexity but it is simply against the reality we experience everyday regarding our whole life.

Seeing things purely from a developer's perspective, the question "why such complexity?" makes good sense, as it's basically all of us who develop for the web, so we want to work simpler, smarter, faster and in a more flexible way. Now, this, obviously leaves the driving force of investing money to create profit out of the equation. The companies - especially the big players, who are the driving force of the particular market - and for any sort of market for that matter, want to have their customers happy by establishing workflows that have certain number and kind of steps and by leveraging technologies (be it JavaScript frameworks, CSS frameworks or anything relevant anyway regarding web) that are well tested, known to work smoothly and have some kind of support, so they can serve their customers in a fast and reliable way. This alone, if also combined with the factor of time i.e. some strict deadlines, introduces a factor of complexity and also to the developer's defense, companies want also to hire less developers highly knowledgeable and experienced and many others that will be just users of specific tools and frameworks, so what they essentially ask is to be specialized in these.

At this point we, developers, have a fair share of responsibility for this situation, as many great people in this field form their own teams and / or small companies and fuel the tank of complexity, in order to secure partnership with big companies. I don't blame this; anyone having the opportunity simply does not trash it but this is the situation in my opinion. On the other hand, for the rest of us, there is what company asks.

But at this point, I would add that a developer can very well follow the standards and have an inquiring mind - provided that he / she loves what he / she does, while on the other hand works with what the company demands. To clarify this a bit, the point that the author of the article makes is to have better fitted workflows and develop using standards and some way of "free style" - in the sense of not locked to specific frameworks and tool chains. Well, this, if put on the other extreme than it is now, would likely mean what we have experienced in the original web in the pre-web2 era, where the word proprietary was the king of the kings for both developers and companies. Maybe this is exaggerated but even if we try to balance it near the "middle", I can't really see a way to work in a structured and documented way by just following the standards, as everyone will have his / her own ways of workflow and coding and most likely will not reveal his / her own trick bag. To be clear, I don't endorse the present divide and conquer fast and furious way for almost each and every piece of a specific technology and being captive to specific frameworks and tools but I don't see an easy way out either. Even in the case of just following the standards with no premade solutions whatsoever, the standards themselves are subject to an increasing complexity just because the whole net is seeking to add more and more demanding services, that have to be supported by equally complex technologies. HTML5 has embraced JavaScript features so the starting point of the scaffolding itself is more complex in its structure while it is not difficult to use. JavaScript has been put on steroids the last ten years or more, so its complexity has increased over the years dramatically and it is not easy at all to use it for any serious web app by just following the standards, at least not in a well structured and well documented way. CSS are also a lot more complicated than it was ten years ago, so the need for frameworks that take out some pain is a given for any application of some serious size. To all these, we must also add testing that is also extremely difficult for any big application, if there is not some framework (likely upon frameworks).

I disagree to the article author on the point of the interplay between back-end and front-end development. In my experience, having the back-end framework generate the front-end is not necessarily a no-go as is essentially claimed. It can be a buggy process but how much is subject to the case at hand and it is the job of the front-end developer to fix the bugs - he / she won't do it manually: there are tools for this and if not, they can be constructed to do this. On the other hand, if a particular project can proceed in a parallel manner between front and back end - well, as parallel as it can be, it is better but it is not always the case.

I also disagree to the point in the "Closing thoughts" that

There are two main kinds of developers: You either come from the world of programming languages or not

The term "web developer" is not a synonym for "web designer". A developer is coming from the world of programming languages - for the web, at least with a knowledge and experience in scripting languages like JavaScript, PHP etc. Although I have nothing negative to say about web design - I learned a lot of things myself in order to support my job, it is an art and not programming i.e. it's a whole different thing. It is just that many web designers got jobs as front end developers during the recent years, leveraging HTML5 premade features and some "ready-to-go" JavaScript frameworks but this does not make them front-end developers, if they don't learn some programming too. This way can cooperate far better with back end developers and systems.

 

[newjerseyrunner]

These articles are mainly complaining about how ridiculously complicated the web development tool chain has become.

That's their own faults, devs should have what they need to work already. Any company will have to go through setting up a dev environment multiple times (basically once for each developer.) If they don't script it, then that's their own stupidity. So about installing brew, npm, bower... someone else who worked there should have already done that. Want to see how quickly I can set up a completely fresh development machine with everything needed?

wget www.intranet.com/dev/installer.sh -O /tmp/installer.sh
sudo /tmp/installer.sh

 

[Klystron]

"Web development at the core is a pretty straightforward architecture — yes, standards. It is more the ecosystems and the complex cultures that had developed by time, which are making everything seem so complex and impossible to achieve. You have to understand that these frameworks and services are there to ease your development — and only that. It is not a requirement, [... edited to redirect..italics added...]"

Accepting the author's points about software developers' libraries, two related factors influence web development work environment:

• The work flow diagram and related configuration management begins with establishing firm requirements (from the company). Before repeating the cycle with design changes, the ongoing product solutions should be evaluated and measured against expectations. Well crafted software may not benefit the end user if the user interface does not perform as expected.

• Requirement descriptions for human factors software such as web interfaces are notoriously subject to revision.

The process of software review with the developers and requirements reconciliation among the principles tends toward revision and increased complexity as the development process instructs the 'users'. IMO actually seeing their ideas implemented on the screen encourages principles to request changes and enhancements in interface software beyond expected revisions in less interactive software even including device control interfaces where the requirements are defined by the 'physics of the system'.

The author's ideas about standard programming languages hints at an aligned process for improving the described software development cycle. The code, tools and skills that produce the desired web page products can enhance otherwise dry metrics such as a graphic indicating how well current development meets stated requirements, color-coded error detection bars from test runs, costs versus productivity compared with number of requested changes.

Take process parts that seem constricting; e.g., code configuration management standards, and use it to the development team's advantage. In this case by creating definitive requirements and managing revisions similar to managing any design change. A topic outside the scope of this thread could explore communication and creative differences among scientists/engineers and, essentially, artists.

 

[verty]

I don't see why there would be creative differences. Aren't they all on the same team? Aren't they all trying to achieve something great? If they keep their criticism constructive, they should be able to work through it or come to an agreement about what the problem is and how it should be resolved.

I found that the communication breakdown was most likely to be between the managers and the staff, because the managers just wanted something out the door already, whereas the staff wanted something that met the brief in spirit. But the staff have to realize that managers don't know the minutiae. They are always going to want simple answers. What is the problem? Why is it not done yet? One has to expect these questions and be ready for them.

Part of the problem is that many developers are young or just starting out and they don't have the experience of office politics that older people would. If older people with more worldly experience were hired, it'd run more smoothly, I think. It also doesn't help that the literati pan everything that is a few years old as obsolete, and everything new as better. This scrum business seems to be detrimental to me because older people are not going to know what the heck it is and why the old waterfall methodology isn't good enough. Surely only young people are doing that. It seems like a bad idea to me.

 

[jedishrfu]

Even between programmers of a team, there is a hierarchy based on time on the team, circle of friends and technical skill aka age. Sometimes if you’re a generation older and have few or no friends, you can be relegated to a lower level, often overruled by the younger team members who don’t see a need to practice your hard won suggested improvements.