Few Tips to Climb

“The limits of my language are the limits of my mind. All I know is what I have words for.

Ludwig Josef Johann Wittgenstein

I believe big part of the absolute computing knowledge is your feelability and conceptual understandability on industrial jargon. Like in any other knowledge area, rich understand and memory of some technical words indeed displays one’s true playability in the field. However, how you know all these words is not how you have heard these words. I always believe a person can explain certain words, and paradigms to its due weight and strength when and only when he start to feel the subject – that is when he has gained enough hands on and brains on experience at conceptual level. The rate or speed of gaining these skills may different from individual to individual. Those who learn fast will move faster. Those skills obviously include lot of reading and some hands on. Naturally those guys who are on the job and in the field always are subjected to better hands on – but they may reluctant to read, explore the knowledge – reaffirm the things with conceptual principles. Nowadays – especially in the computing, medical and , engineering fields – people are much loyal towards vendor technologies and vendor terminologies. This dogma completely but sneakily bury the theoretical principal knowledge, and unknowingly produce a loyal set of converged customer’s to a particular technology provider (vendor). This happens so unknown to the Engineers, Lectures, policymakers – danger is that, such vendor orientations hinders new knowledge generation, creativity and more dangerously industry leave no free mind to the Engineers of old Versions of the same technology. 

I always see a huge advantage over learning principles and remembering them thoroughly when you go up in the career ladder. If still you want to be a code monkey – passionate for hands on code, my approach has a good apply than trying to remember various vendor technologies in line. I always suggest students to dig in to the principles – and start to see the vendor technologies through these principles. This makes things easy to remember. Moreover you will be a Creative solution Designer, worthy problem solver and a celebrity philosopher in your respective specialization been you - yourself.

Upon my experience in the field of software engineering for quite some time, I have seen following are some key habits of SMART well paid engineers who could easily remain unharmed and fearless against the dynamically changing turbulent technical paradigms.  Habits are quite important and well hardened through developing various self-skills. 

So what could be these skill driven habits – which could transform you towards so called smart professionals?

1. Put more effort to be a speed smart typist – Master Touch typing, Keep a healthy WPM rate. Never feel lazy to type. If you happen choose typing than copy and pasting – always choose typing. You will be much stronger and uncatchable for others. 
2. Get your communication skills ready – how do you speak meeting, what to talk, what not to talk, how to summarize your thoughts, always Google for new words. 
3.  Never learn to compare yourself with others – be yourself always, try to master the skills you specifically look for. 
4. When you work with your team members – don’t feel them as comrades, and never treat them as rivals, or competitors. Always share what you know, but never expect others to be so.
5. Learn good work ethics and try to establish them in you. Never criticize your bosses, subordinates and peers with others. If you have concern, feel genuine and brave to talk directly and personally. 
6.  Always remember – Silence is SAGE (“silence is the language of god, all else is poor translation.” ― Rumi)
7. When you see others are having good qualities/skills, never feel jealous. Out of admiration, develop them in to yourself with effort. Simply been humble is been always willing to learn.\
8. It is also a must that an individual must develop the habit of reading. With limited time you can’t expect to read everything on web and books. So for example you must find few good must read books from industry like programming and code quality. They will include - The Pragmatic Programmer: From Journeyman to Master Clean Code: A Handbook of Agile Software Craftsmanship, Code Complete: A Practical Handbook of Software Construction, Second Edition, Structure and Interpretation of Computer Programs - 2nd Edition are few suggestion from most good software engineers. So specialty in these books are such that they are globally accepted as must reads for any software engineer by most branded software developers.

Why it happen specifically to highlight these behavioral characteristic with the top priority was that that in my contextual experience specially at the Sri Lankan Software Industry, I have witnessed people – coming from universities and general rural back ground, may not believe in these habitual small tips which can bring huge differences to their careers.

When it comes to technical paradox – many people in the industry I find are vendor oriented and top job driven. I have seen lot of youngsters believing talking to their friends, that earning good technical certifications, earning good educational qualifications will help them to earn good remarks in the industry. To me I feel that is the most illusiest magic a green horn never should believe. I have even seen their world of industry is always more or less about what it has been requested in 100 daily software job advertisements – published in newspapers, web pages or through email advertisements. So as you find in law of attraction, if you want to grab a thing, change your doom - you must always clear your wishes: Specially HOW and Whys. (how you get it, why you want to get it and where you want to be). Then only the universe will start to materialize the ways  for you to get there. Otherwise you are just thinking and hanging on your imaginations and thoughts yet have not achieved any pragmatic results. What could make you a pragmatic ideal software career. Perhaps you have already come across the below’s – but have not felt faithful  enough to believed that they could be the key secrets.

Taking an average Java developer in to example – try to see the things in different paradigm. Instead spring: learn the principles of following. 

1. What is dependency injection, late binding/early binding/ dynamic bynding, XML binding 
2. How do you inject dependencies between two classes (write your own example)
3. What is inversion of control and How do you really invert the control – what are the well-known ways ? 
4. What are crosscutting features - How do you bring down crosscutting features to general aspects? 
5.  What do you mean by a light weight frame work – try to write your own light weight DI framework with the support of XML. 
6.  How does annotations work.

Instead Struts/GWT/JASPER/AJAX:

1. Just remember what are the front end J2EE technologies
2. Put lot of effort to learn  Http Protocols : What are the well-known http methods and error codes
3. How do you troubleshoot server back end and web deployment in web containers (application servers/web servers) 
4.  How do you communicate between two programs in two different computers? 
5.  What are the designs based differences between asynchronous and synchronous communication / RMI and message driven communication. 
6. What is truly meant by middle ware and what are the mostly available different middleware technologies: what is the principle

Instead learning libraries: Learn object oriented programming.

1.  Always remember few key easy design patterns with example - Remember at minimum the name of 23 GOF patterns, with why they use - where, when etc into (structural, behavioral, functional) paradox 
2.  Never forget the concepts of Object Orientation at OOsA OOsD and OOP (coupling, cohesion, abstraction, polymorphism, encapsulation, dynamic dispatch, dynamic binding)
3. Learn about few compilers, and principles of how mechanically an OO programming language work (Rutime Compile time differences, core technicality of compilers, difference between CLR and JVM etc) 
4.  Learn Object-orientation for databases. Not Hibernate/Toplinc etc. First note the Relational data aspect (Entities and Relations) and then the Object model (Classes  and association). Then  Try to see Object-Relational Framework characteristics. Also look at Object-relational impedance mismatch, Object-relational mapping (Who care hibernate, Toplink or any other ORM tool J ), and Object database, NO SQL  like Mongo DBS etc.
5. Highlight is : Never forget the Software Engineering part. Big part of leading a Software team belongs to less coding, but good software engineering skills. Therefore never forget Requirement Analysis, modeling  and Engineering (UML, various diagrammatic approaches (use cases, collaborations, classes , components , interactions, etc)
6. Never undervalue the model level knowledge on areas like (RUP, Agile, TDD, Scrums). 
7. Get use to some estimation skills like – functional points.   

Always remember good programming habits and few principles of quality code.

1. Principles of quality code and how you achieve them (maintainability, scalability, extensibility,  Open Close principle,Fail Fast, Separation of Concerns.) 
2. Code quality assistance tools (Check Style,  eclipse plugins etc …) 
3.  Best Practices (naming, styling, refactoring, modulating etc etc)

Instead learning much vendor EJBs, ESBs (oracle weblogic, IBM websphere, WSO2).

1. Read about Principles of Distributed Software Design and Development (Enterprise Scale). 
2. Learn the principles of middleware and message driven communication /product level advantages / disadvantages 
3.  Learn concepts and granularity always : what is a bus in computer science try to simulate your own bus between two computer programs, What is a container, what is web container, What is a marsheller,  dispatchers, Demons, Schedulers, Work flow engine, Rules Engine, etc … 
4. Learn  the principals of Transaction management (ACID atomicity, consistency,  Isolation – Isolation levels, Durability) 
5.  Learn different ways of implementing web services (Restful, message driven, RMI based ) 
6. Learn just extended technology modules like WS-Security for SOAP, which possibly uses to implement web service based security and the security principles. 
7.  Always Always Remember Security Principles (2/3 factor authentication, Public – private key encryption,  Kerberos, and  Always learn, remember about the common words on security threats.Learn about security terms related to web technology. (eg :Cross Site Scripting, SQL Injection, PHP Injection, Javascript Injection, Path Disclosure, Denial of Service, Code Execution, Memory Corruption, Cross Site Request Forgery)

Learn XML

1.       Learn X-paths, X-Path tools, XML bindings, DTD, SOAP, WSDL, XSD, XML DOM, DTD, XQuery, :D

As many says, to which I also agree, the most effective way of learning new and potentially confusing thing is implementing those from the scratch. It is always a must remember for inception there may no need to develop high-quality stuff. Quick and dirty implementations should be more than enough. Habitually – if you can start a thing, that is important. Then keep continue. For example if you really want to learn how a search engine works, go ahead and write a rudimentary one from the scratch.  Remember Nothing will work unless you do – (Maya Angelou ).

Last But Not Least. Below is what one quote one day  one my very good friend and the reviewer of this article Upul Bandara found during his research. I think the same act as a key to rocket you to the destinies where you like to see your self within short.

They say that you're the average of the 5 people you spend the most time with. Think about that for a minute: who would be in your circle of 5? I have some good news: MIT is one of the best places in the world to start building that circle. If I hadn't come here, I wouldn't have met Adam, I wouldn't have met my amazing cofounder, Arash, and there would be no Dropbox. One thing I've learned is surrounding yourself with inspiring people is now just as important as being talented or working hard. Can you imagine if Michael Jordan hadn’t been in the NBA, if his circle of 5 had been a bunch of guys in Italy? Your circle pushes you to be better, just as Adam pushed me ...

Seeing Many Biographies of world renown professionals - Like Einstein, Tesla, Newton, Linkon, so and so, one could also say that it is the network they kept and nurture regularly, the time they spend on their topic with regular symposiums seems be what contribute majorly to push their ideas and rectify them to near perfection with due recognition. You know what I mean.

Hot To Code Quality ...

Today the business world is so dynamic. Expectations, needs and wants of people are changing instantly at non predeterministic unpredictable way. So do the Business Requirements. Hence it is inevitable that the software you develop today will always in need of dynamically changing it's capabilities in order to cater the various changing customer expectations. The challenge is exceptionally high, as in this industry (Software Industry), the technologies are changing even at a faster rate. This back ground paves the way for this article, on the need of writing quality code.  What do you mean by quality code?, why code quality is this so important? And how you write a quality code and what are the areas to think about? Following is a research about the same. 

As provided the dynamic nature of the industry, Software cannot be developed for life time, so that they meet the requirements of everybody for every day.  Therefore once the requirements change for existing customers, or once the existing product is needed for new customers with some modification, the product will have to scale or enhance for new features. When new technologies arise, and when new dependencies are introduced,   when you find bugs and vulnerabilities, you will have to maintain your product for stabilization. In either ways it is part partial that you maintain your product to remain sustain in the business. So code quality is directly involved with the sustain Engineering of any software product. Today many software companies spend millions of money in maintaining their products. Sometimes one would not believe, that generally maintenance cost top your cost structure of annual reports for majority of Software Development Organizations. Therefore " A quality code" is strategically such very important as it is the only sustainable way for your organization to reduce the rocketing maintenance costs.  

Following section will look at the issue from more technical perspective and will reveal some vital concepts to help you develop the code quality.

Generally quality of the code can be qualitatively discussed in terms of the following. 

a)      Readability 
b)      Extensibility 
c)       Reusability 
d)      Maintainability 
e)   Testability
f)      Design time concerns - The open closed principle 

Code reviews are the very famous ways of reviewing the existing code, in order to conform that the code meets above.

Readability

Readability of a code is vital as reading the code is the only way so that the feature enhancement developments, bug fixing, maintenance can be easily carry on. It is an inevitable fact in the software industry that original developers may not stay long with the project, so that the developers, who have the actual familiarity of the code, may not stay prolong for the maintenance cycle. With this tentative nature of employment turnover in  the business, generally software organizations may have to start maintenance work with brand new members who have no previous understanding of the code. More over, only very few small and medium scale organizations would maintain the costly learning organization. (design specs, training documentation,  product documentations,  Proper version control, release management, history logs, etc.) Therefore readability of the code is extremely vital for the reduction of maintenance effort and finally the maintenance costs. Readability meaning the ability to easy understand the code, its logic and the functionality it delivers with minimum effort.  For example, there  may be programming STARs who could write logic in two comprehensive lines, which general average developer may take 20 lines for that. However, the negative impact in such a STAR case is, since there is no compromise, shortening the code naturally enhance the complexity. So do it enhance the maintenance effort. Finally the cost of maintaining such bright code will be high compared to an easy readable code.

How do you enhance the readability? 

Readability improves once you reduce the complexity. Complexity may be due to various reasons. It could even include facts like complexity of the logic, complexity of the implementation, complexity of the math, complexity of the usage of programming language (Lambda functions, recursion, nested logics etc.). I consider reducing complexity is one part of enhancing readability. There are there universal coding practices which could help you to reduce the complexity of the code. Here directly i relate my thoughts to what you find in the web. 

1. Partitioning

A concern should be given to logical and understandable way of modularity considering separation of concerns. Partitioning Reduces the number of factors that have to be dealt with simultaneously.  It narrows the focus of attention. However improperly over partitioned, it could enhance the complexity.

2. Hierarchy 

Directs the span of attention and allows for levels of detail. This aids in the later construction and easy understanding of systems. The shape of the hierarchy is important and should reflect the functionality of the system.

3. Independence
 
The most important idea behind a lot of structured design is "High Module Independence" Objective is not simply partitioning a program into a hierarchy but determining the structure such that each module is as independent of all other modules as possible. Independence is generally achieved by minimizing the relationships between different modules (Coupling) and Maximizing the relationships amongst the elements of a particular module (Strength/Cohesion). The independence terms can be also achieved by making the responsibilities independent.

Following too could be very useful in formulating your ethos for readability. No argument about being DRY.  So you are correct. The concerns here are quite coherent with the primitive three facts I described above. 

• Consistency

Applies to formatting, using braces, naming (variables, classes, methods, good uses of white spaces, refactoring)

• Size

If a function doesn't fit in its entirety on the screen in a normal IDE at a normal font size then you need a pretty darn good reason as to why not. Of course there are some valid cases for much longer functions but they are greatly outweighed by the egregious examples. Decompose as necessary to keep your functions simple.

• Comment Judiciously 

There is a tendency for some programmers to use comments as a substitute for readable code or to simply comment for the sake of commenting (like /* finished */ comments right before return true;. Seriously, what's the point? Most (good) code explains itself. 

• Avoid repetitive codes

If you find yourself writing the same sequence of statements (or very similar) over and over again, abstract or parameterize it. If you see very similar statements the tendency is to skim over them assuming they're all the same (when typically they won't be in a way that matters). DRY: DRY stands for Don’t Repeat Yourself. Also known as DIE: Duplication is Evil. The principle states: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

• Careful when you use frameworks

 For example, when you use certain frame works and their inherent features eg: Autowiring of Spring, the introduced dependencies will make things very hard to understand as such frame works hide some layers of operations in the code. This make very hard to understand the code even for those people who have a good understand on the frame work.

• Avoid Deep Nesting

• Use Short BUT meaningful Names

• Single Responsibility Principle

Break code up into meaningful pieces that accomplish specific purposes.

• Clear Design and Separation of Concerns

Separation of responsibility between components (class, function, etc). This will include Keep your classes cohesive (it all works together) and decoupled (there are few dependencies between classes).  On the other hand this can be described as Separation of Code and Data.  Keeping a good modularity and a meaningful folder structure will also be useful here.

Extensibility

In software engineering, extensibility is a system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change while minimizing impact to existing system functions. 

a)  Dependency injection.

Frame Works - provide a reusable context for components 
b) Component Technology (DCOM - Microsoft, SUN - Java Beans) 
c)  Use of Design Patterns 
d) Proper moduleing

Proper moduleing enhance the extendibility as it separates different concerns. 

e)  Separation of interface and implementation

Object-orientation allows us to specify the binding between interface class and implementation class in the following ways 
 i.      Class-based inheritance: whole classes are related by inheritance. The pattern of inheritance is fixed when the classes are created. 
ii.      Delegation: objects can be individually related, enabling each object to make its own decision as to when, and to what, it delegates. The pattern of inheritance can vary dynamically, making delegation a more flexible and powerful way of organizing objects.

Maintainability

Maintainability of the code – Provided the importance of software maintenances and considering the importance of service packs, patches, bug fixes as part of service agreements, or attempts of product stabilization,  here I would focus more on proper documentation, proper release management, proper historical information record and proper versioning on software development than any other fact. The argument is software should well maintainable. In order to track the bugs and the issues, keeping historical records on the releases, is so vital so that developers could easily capture a particular bug to a particular released version or afterwards.  

Reusability

Reusability could be achieved through various concepts that were defined above as well.  However I would also list some concerns below which could be useful when it regards reusability. 

a)    Remove the business logic or main code away from any framework code 
b)   DRY 
c)    Write unit tests for your classes AND make it easy to test classes. (TDD) 
d)    Single responsibility principle 
e)    Try to think more abstractly and use Interfaces and Abstract classes. (dependency injection) 
f)     Reduce coupling 
g)    Be Modular 
h)    SOA Reusability

a.       Services reusability

b.      Services orchestration

c.       Service Automation

Testability

As far as any software project is concerned, testability should be one major design time concern in order to make sure the ultimate functionalities are met. More than that generally large scale software products also  have various test sets, so that before releasing a new version, service pack or, patch, it is a general habit run those vital automated testcases. Orthogonal code design enhance the testability.The things have to consider here include

1. IOC/dependency injection
2. Use of frame works

 Other Design time Concerns - Open Closed principle

The Open Close Principle encourages software developers to design and write code in a fashion that adding new functionality would involve minimal changes to existing code. Most changes will be handled as new methods and new classes. Designs following this principle would result in resilient code which does not break on addition of new functionality.

Must know not just about Software Licenses

We – Software professionals like everybody else down streets know that you need to have license to use licensed software, and you need not license to use open source software. Licensing was not an issue in majority of the Asian part of the world a two three years ago. However even that picture is ridiculously changing now. As project managers who travel across different geographies you must have to know precisely at least different type of license agreements and their respective legal obligations.  

One very confusing area is that terms free software and open source software are used interchangeably. I have borrowed following philosophies related from GNU. “In 1998, some of the people in the free software community began using the term “open source software” instead of “free software” to describe what they do. The term “open source” quickly became associated with a different approach, a different philosophy, different values, and even a different criterion for which licenses are acceptable. The Free Software movement and the Open Source movement are today separate movements with different views and goals, but may be they do work together on some practical projects”. Therefore I believe there is a propaganda based term clash between Open Source vs Free Software founders to demark their territories in the competitive landscape.

The TERM clash - Open Source vs Free Software

1. A free software license Definition

 : is a software license which grants recipients extensive rights to modify and redistribute, which would otherwise be prohibited by copyright law. To qualify as a free software license, the license must grant the rights described in The Free Software Definition or one of the similar definitions based on this.

2. An open-source license Definition

: is a copyright license for computer software that makes the source code available for everyone to use. This allows end users to review and modify the source code for their own customization and/or troubleshooting needs. Open-source licenses are also commonly free, allowing for modification, redistribution, and commercial use without having to pay the original author. Some open-source licenses only permit modification of the source code for personal use or only permit non-commercial redistribution. All such licenses usually have additional restrictions such as a requirement to preserve the name of the authors and a copyright statement within the code. One popular set of free open-source software licenses are those approved by the Open Source Initiative (OSI) based on their Open Source Definition (OSD).

What is important?

Therefore even provided the above definitions I too could not still find a clear difference between Open Source and free Software in terms of the purpose they stand unless otherwise the differentiation of the terms of license granting body. Let’s forget the craps for a moment and see what seriously we really have to know. I have heard, that starting in the early 2000s, number of companies began to publish a portion of their source code to claim they were open source, while keeping key parts closed. This led to the development of the now widely used terms free open-source software and commercial open-source software to distinguish between truly open and hybrid forms of open source. This is such a critical situation where as project managers we have to be careful and understand the legally obligated nature of the license. It says generally Free and open-source licenses generally fall under two categories: Those with the aim to have minimal requirements about how the software can be redistributed (permissive licenses), and those that aim to preserve the freedoms that is given to the users by ensuring that all subsequent users receives those rights (copyleft Licenses). I think this is the point where most writers and speakers deceive us. Knowingly or unknowingly they may be using the term Free Software for the Copyleft license and Open Source for the permissive license. Correct me if I am wrong. 

Copyleft license	Permissive license
Eg: GNU General Public License (GPL) Note: Any modifications made and redistributed by the end-user must include the source code for these, and the license of any derivative work must not put any additional restrictions beyond what GPL allows.	Eg: MIT license (Massachusetts Institute of Technology) BSD license (Berkeley Software Distribution) Note: Gives a user the permission to take the code and use it as part of closed-source software or software released under a proprietary software license.

Figure:  The distinction between Copyleft vs Permissive license

So in brief, the GPL license impacts "derivative works", but the MIT/BSD license does not.  This has huge implications.  If that too complicated - Let's take the following examples.

Code G is GPL licensed.  Code M is MIT licensed.  You wrote X.

You create project GX which contains your code (X) and G.  If you distribute GX (the source or binary) then you have to make GX available (this includes X -- your code -- which you might not have wanted to make available).  Why?  Because if GX is a derivative work, then GX is also licensed under GPL.

Note -- let's now say that someone takes your GX (since you published the source code) and makes GXY (by adding his Y code) -- now if he distributes that code (or binary), then GXY has be licensed under the GPL and the source code has to be made available.  This is a property that some people call "hereditary", other call "viral", and some prefer the pun "copyleft" -- which is the opposite of copyright. 

Let's now create MX which contains your code (X) and M.  If you distribute MX (code or binary) then you have to indicate that part of MX contains MIT licensed code.  But you don't have to say how much of it does, where it is used, how it is used.  You don't have to make X available.  And you can license MX any way you choose. You can license MX under MIT if you want, and publish it.  You can also license MX under GPL -- (you'd be licensing MX, but not altering the license of M -- since it's not your code to re-license).  You could also sell MX under a commercial license.

Note -- it would be pretty difficult to sell GX since anyone can get the source code from you -- so why would they buy it?  Moreover you cannot add any restrictions onto GPL licensed code -- so you cannot, say give it for free on the condition that someone donate a $1 to charity.  So in effect, if X is a valuable asset to you, creating GX (and distributing it to a 3rd party) just devaluated it.  This will cause some to be concerned about using GPL code if they deal with other code they value (e.g. have patents, secrets, etc.) 

Credits 

Google/Wikipedia

Charaka Danansooriya