Typical "Weak Spots" of SW Developers

I started my programming career with the "notion" that GUI is an "auxiliary" and "secondary" thing in any great software product. My mentor and boss was pretty "bad" in GUI and in the Look & Feel aspects :-(... And I also could successfully copy this weakness from him (I wish it implied that I copied all his great strengths ;-)..

With the legacy of a "Great Mentoring Tradition" most of my "disciples" also "inherited" that "Great Weakness" :-(... I am also surprised to see that most of our Computer Science and Engineering students also painfully lack this "User Interaction" Focus ! I often hear this statement: "I am now doing boring Forms or Reports Design!" Yes, s/he has a point: "since I am NOT a GUI designer, so I should not be doing this".

But another stronger point is, You simply can NOT ignore the importance of GUI (Graphical User Interface) and its implications. You HAVE to train yourself to have the "eye" and "skills" for consistent GUI Design and Development. So even a "one pixel error" should not miss the eye of a skilled Software Developer. And I am very convinced (from my own early-career-mistakes) that it can be learned, and it is mostly a matter of attitude and giving importance and priority like other programming and software design skills.

I have also observed that fresh developers are NOT well-oriented with practical SQL building skills for RDBMS (Relational Database Management Systems) and Database Table Designs. May be in the Universities / Colleges, the algorithm-focused Computer-Scientist Professors do not take a lot of interests in the "not-so-exciting-proven-relational-algebra thing". But it is very important for almost all practical business applications.

Performance Issues also take a back seat for most fresh software developers. Surprisingly, many business applications developing software companies in Bangladesh also do not demand it from all its beginner developers. The usual notion is: "Build something first real quick, and then we will see what we can do to improve performance later". Not a bad thing to start with ! But in this process, often the needed "measurement mind-set" gets lost :-(... We can not manage something, if we can not measure that.

Have you "really tested" your code ?
"SURE. I ran it 10 times !" ---- This is the typical answer from most Software Developers !

Can you "scientifically prove" that your code works ?
"WHAT ??. What do you mean?" ---- We might be up for a fight now :-(... The ego gets hurt here !

Quite often the Software Testability Issues are NOT addressed properly by most Software Developers, Managers, and even Users ! In most other engineering and scientific professions, there is always the concern for "proving something scientifically with data and validations" ! Software development as a nascent profession is still largely free from this obligation ! But those days are quickly passing by !

A World Class Software Development Professional MUST be able to "scientifically prove his thoughts with real data and validations". This may start with the UATCs (User Acceptance Test Cases / Criteria) and followed up by the STCs (Software / System Test Cases / Criteria), ITCs (Integration Test Cases), UTCs (Unit Test Cases). A Software Developer / Designer / Programmer must write thorough and useful Unit Test Cases to build the blocks for a thorough scientific scrutiny of the full software product.

In this constantly changing user and technology environments, a well-built Software Testing Scrutiny System (where everything can be programatically verified and validated) can act as great health checking, measuring and metering devices as found in other sound engineering disciplines. Test Driven Development (TDD) and Agile Methods are not just some fads or fashions of modern time. They are the needs of the current time, and should be used with the true spirit.