HƯỚNG DẪN Software Engineering must be learned?

Joe

Thành viên VIP
21/1/13
2,882
1,287
113
Hi

For the "IT-Illiterates" everyone who "adeptly" plays with a smartphone (Android/iOS) or with a PC (mostly Windows) is a Software Engineer. And worst of all is that some of them believe IN the (wo)man as THE Software Developer. Well, they err and most of them make a fatal mistake to employ the "playing gurus". The outcome is foreseeable and it's usually a disaster. Even in the "advanced nations" like Germany, France or the US IT-Illiterates make the IT world becoming a woodoo world full of bugs and problems with their employed Playing-Gurus. Billions of dollars were spent for an awkward-malfunctioning "Software". This playing guru, no, this "Software Engineer" is usually an eunuch or an one-eyed man in a group of the blind -the IT Illiterates. Newly, an old friend asked me for my opinion about a "Software Engineer" who reasoned why JAVA is "hated" by Software Engineers. And he brazenly posted his arguments on the QUORA site. This "Software Engineer" confuses JAVA, an OOPL, with a Framework+IDE+Tools (Ant, Maven). It's hilarious to read his gibberish "arguments" (click HERE to see for yourself his weird arguments).

Software Engineering, or to be precise, Software development is a HIGH ART. It's about the visualization of abstraction. Sketching a beautiful girl does not make the "sketcher" to a painter of Van Gogh or Picasso class. The Art as we know in Painting, Musics and Sculpturing. It's impossible to demand that those who code must be the exceptional artists. But like in the painting or music world it is sufficient that the artists know what they do without having to be famous. Exactly that, a Software Engineer should be capable to master the Coding matters he or she works with without having to be an IT genius of category Jame Gosling (JAVA) or Guido van Rossum (PYTHON).

The Software Engineering problems are the lack of imagination and of initiative. In an IT department of Company X the CIO (Chief Information Officer) is the one who sets the standards and that is the root of all Software Engineering problems. Because the CIO is somehow adeptly with Framework X and quite versed in an IDE Y that works with the OOPL Z the CIO usually employs or demands the applicants or the underlings to know and to work with the framework X and to code in OOPL Z with the IDE Y.

SoftwareEngineer_1.png

The scenario can be observed on the newspapers or on the Head-Hunter website with the job-offers. The demand for a knowledge of a certain framework, of a particular IDE and of a certain OOPL is omnipresent. All that kills the imagination and initiative of any dedicated Software Engineer. Imagine that Van Gogh or Picasso had to paint something according some fixed patterns designed by his sponsor. The resulted "painting" would be certainly disastrous. Even both painters were famous and ingenious. If a software engineer is forced to work with this framework and with that IDE together together with this OOPL the result is foreseeable: disastrous and mediocre.

The situation could worsen when the company hires a new CIO who hates Framework X, loves IDE Z and Framework Y with OOPL X. His or her very first engagement is to introduce his or her "pet-products." The affected get an endless nightmare. Learning a new Product is always hard. The tricks and the "configuration possibilities" for a framework and for an IDE are numerous and no one knows for sure how the whole bunch works. Then, the new OOPL whose APIs must be learned by heart, gotten familiar with. The learned old knowledge is flushed down in the toilet. One starts as a newbie again. If his expectation is unachievable the new CIO tries to "replace" the team with his or her self-chosen people. The worst thing is that there is in a team a smart "playing guru" who could speak fluently of this and of that, always has some "great" ideas and expertly knows how to "shove" the work to the others, then claims the work is his when thing is functionally complete.

SoftwareEngineer_2.png

Such playing guru is usually an ASAP guru (As Soon As Possible). The IT basics is not his domain. Things such as "NullPointerException" or "NumberFormatException" is for him or her the coding mistakes of the colleagues. At the end: the good leave the company. The bad merge anonymously into the team and that is the reason why and how a company slowly hemorrhages to death.

SoftwareEngineer.png

The basic knowledge is often ignored or misunderstood as the "primitive" things that a Software Engineer needs NOT to waste his or her time for it. Some "Software gurus" even don't know how a binary operation works. A simple binary addition of 2 binary numbers could cause some headaches to such high-flying gurus. The repetitive mantra "I don't intend to reinvent the wheel" justifies the avoidance to move into the world of the basics. Instead of doing some basic research some software gurus spend their time on the web for searching some ready-for-use packages or APIs. And the CIO who mostly resides on the politics-making cloud won't care a bit about what his or her underlings are doing. His or her only goal is to secure his sitting chair. The IT result is for the CIO secondary because it's clear that NO software in the world is bugfree, isn't it? That is the basic problems of Software Engineering caused by people who are scared off the details. To cover their lacking enthusiasm for the basic details the CIO and his or her team stick firmly to a certain schemata: Framework X, IDE Y, OOPL Z. No room for any further imagination, nor for a minimum of self-initiative. The outcome is constantly mediocre. A mediocre software created by a mediocre IT team.

The monotone work with one Framework, one IDE makes the good to the evil bad. The software gets numerous layers. And each layer is dependent from one or more other layers so that no one in the position to comprehend the project as a whole. The long paths, the myriad subdirectories which are usually created by Framework and IDE and the bundle of "Annotations" that no one understands what they really mean and how they exactly function, or why a project must have so many subdirectories and different configurations. A mysterious myth for everyone. And the Software Engineers spend most of their time to struggle against the weird conventions and to "debug" the hidden bugs produced by their own codes, by the Framework and by the IDE. Indeed, there's no time for an own initiative.

Due to lacks of own initiative and the forced working with tools (Framework, IDE, OOPL, DB, etc.) demanded by the CIO (or the project manager) most of the software projects run out of control. The software engineers are unnerved while the ASAP gurus triumph with recriminations. It's easier to talk than to do. Talking is the domain of ASAP gurus. "Words can move mountains" says a proverb. The ASAP gurus always win. The software engineers always are the losers. The software becomes unmaintainable. The most dangerous reason is the encapsulation of (coding) knowledge. Codes become spaghetti, unmodular like a spaghetti plate.



It is hard to maintain the spaghetti codes. When you take time and look at a generated GUI (e.g. Java SWING) from an IDE (e.g. Netbeans) you won't wonder that the "coders" dare NOT to touch the codes -and the threatening warning is therefore comprehensible "don't mofify...." It is almost impossible to detect and to remove a spaghetti bug (generated by an IDE). Or in one word: Nightmare. The software becomes the most frightening nightmare to the users. A guy who claims to have years of "development experience" (like the guy who argued why JAVA is hated by "Software Engineers" -like him, of course) said that since he works with "Ruby-on-Rails", an application framework, his codes are becoming better:
the framework facilitates to produce 'slim and willowy' codes
Wow! If so, why his company hires him (as an expensive IT expert) when "Ruby-on-Rails" produces the finest codes for those who use it? It's much cheaper to hire a man around the corner and tell him how to click "Ruby-on-Rails". Am I right here?

The CIO and some "self-named" software engineers of his or her team believe in the new religion: Framework & IDE. The programming language (OOPL) is just an appendix. Unimportant because Framework like "SPRING-BOOT" or "RUBY-ON-RAILS" is the Magic Box. It conjures and delivers the fancy codes whenever one needs. Why JAVA? Why PYTHON? Why C#? Magic Box Framework supercedes them all. And that is the beginning of a downfall of a company. The CIO of Boeing was probably the best ASAP guru who had somehow successfully convinced his company to "outsource" the coding works to somewhere where the fancy "slim-and-willowy" codes were mass-produced (probably by such a Magic Box Framework.) It saved not only money, but also the expensive human resources (programmers). Boeing is currently struggling to survive after the 737-MAX disaster. Poor Boeing.

The magic word is Framework and the magic tool is IDE. Together the CIO and his Software Engineer Team (SE-Team) believe to attain a wishful Magic Chest. With it they can conjure everything: AI? No problem. Big Data? A piece of cake. Machine Learning? A childplay. BUT: when things went wrong the CIO and his or her SE-Team ran into panic and often went berserk. The "JAVA-hated" man from QUORA, for example, complained about the long paths (which are by convention of his Magic Chest), the cumbersome download of "Ant" and "Maven" (which are the integral parts of the Magic Chest). From the lack of knowledge the CIO and his or her SE-Team start to commit the unthinkable: they look for salvation in the Outsourcing realm. And that was exactly that what Boeing had done. They, the CIO and his SE-Team, propelled themselves into the realm of nonentity. One has to ask oneself what the CIO and his SE-Team are doing during the day when the coding works are done elsewhere? Maybe the CIO and his SE-Team believe in their superiority as the "Ideas-giver" (specifications) and the poor guys who code must be too unintelligent to devise for such ideas.

Well, what next if a GOOD Software Engineer or a GOOD CIO shouldn't trust the wishful Magic Chest ? Software Engineering must be learned. Not everyone has a natural talent (i.e. self-didactic) to code. Therefore we have to learn how to code just like a painter has to learn how to work with the paints. Bad paint mixture reflects an unnatural painting. Bad coding reflects the immatureness of the software.

1) Don't stick to any Framework or IDE or OOPL
A Software Engineer, good or mediocre, must be in the position to develop a workable app without Framework and IDE, and on that what is available for him or her. For example: with the "notepad" of WINDOWS or "vi" of LINUX/UNIX, in JAVA or C# or C++ or PYTHON. The learning process is always an epiphenomenon or an accompanying effect for every (Software) Engineer. Otherwise he or she shouldn't boast to be an Engineer. An Engineer always learns something new in his work -even the work is a dull chore. The gain is either an accumulated experience or a satisfactory Aha-Effect. There ain't no such thing as a wishful Magic Chest. Those who stick to a certain Framework and to a certain IDE are never good in initiative and imagination. The Framework and the IDE take over the imagination (thinking) and the initiative (trying). Everything that needs to be done can be done with a mouse-click. There is NO ROOM for an imagination and an initiative.

2) Don't trust any machine.
If a printer stutters or ceases to print it could be the driver of printer, or the OS-Update with some feature changes that make the driver running into troubles, etc. It is NOT always the problems of your app. If you know your app as THE developer (or engineer) you could relatively quick locate the source of the troubles. Only those who are unsure about their app run into desperation.

3) Don't trust any alternative option
The more you try to hedge something with additional options against something the more you let something open for intrusion. It's the paradox in the matter itself. More security is the same with more vulnerability. The reason is simple and is in the human trait of being as effortless as possible. The coercion of at least 8 letters with special characters and digits for a password usually leads to an easy-to-guess password. Example: Joe.30.5 (Joe, birthday and birth month).

4) Don't trust the consultant and the salesman
Backup? Security? Encryption? The salesman or the consultant will tell you that the "package" does the backup itself, secures the data with an unbreakable encryption algorithm, etc. Meaning: you need nothing to do. If so why the company employs you? A Software Engineer should do the basic works and shouldn't depend on any "ready-for-use" package told by an ASAP guru. Otherwise he or she should call him/herself an Application Engineer, NOT as a software developer (or engineer).

5) Don't ruminate the old grub
Certainly you have often heard of the old grub "I don't want to reinvent the wheel again". BUT: if you look at all the famous software you won't see anything new, but the different kinds of "reinvented" wheels. LINUX? A derivate of UNIX. WINDOWS? A variant of the old Apple OS. SunOS or MacOS? A BSD-Unix derivate. JAVA? A mental child of C. PYTHON? BASIC is certainly the forefather. And so on. See? All these famous software are the "reinvented" wheels. Or to be more precise: every useful software is a build-up on an existing software (knowledge). If Ken Thompson followed the old grub "don't want to reinvent the wheel" then UNIX wasn't existed. And we don't have today JAVA, C#, PYTHON, SunOS, iOS, Android, Red Hat, Ubuntu, Windows, etc. when their creators didn't want to reinvent the wheel.

6) Go Open Sources
Open Sources are the true software that really works. The reason is that Open Sources are public and everyone has access to the sources, can copy, can enhance, can optimize and can contribute his or her work to the Software community. Like the ants, millions of contributors work with the sources and make the (Open) sources better and better and better. The public fora are, for example, the place where Software is made, enhanced, optimized. Everyone can contribute a share. It's therefore selfish, stupid, disrespectful and reckless to post a question on a forum without showing the source. And when the questioner got a hint or somehow an "illumination" (thanks to the hint) and could solve the problem by him/herself but he/she kept it from the forum as if it was a valuable, unshareable asset. It's against the Open Source philosophy and against the community of a forum.

Joe
 
Sửa lần cuối:

Joe

Thành viên VIP
21/1/13
2,882
1,287
113
...and here is a Stackoverflow's screenshot showing you a man whose app runs within his Framework Spring & IDE IntelliJ but fails to run in a "naked" environment -outside his "familiar" Spring & IntelliJ.
stackoverflow.png
 
Sửa lần cuối:
  • Sad
Reactions: quydtkt