How to deal the most severe Technical issue in developing Enterprise Scale Software

The background for this post is my experience relate to Software Component Integration for enterprise scale projects. After a component Integration stage in a Software development project, for me the most severe technical issue observed is Performance. The end to end performance realities can not be often tested and measured till the final phases of a enterprise software development project. Once you actually start integration the components only, you will start to realize the planned technical architectures and implementation/deployment activities not achieving the planned performance and consistency target as expected. Always planned situations are very much deviated from the final results, when plans are over judged and planned work is not correctly tracked and measured for control.

For years I have been thinking why many software projects exceeds their budgets, and schedules specially during this last phases of Software development life cycle at large scale (over 100 developers) software projects when we start to do component integrations to produce the final product. Perhaps my observations related such projects are very pessimistic, when it comes to the final stages - close to delivery.

Generally - until few month before delivery, the enterprise applications will be developped as separate components. They will either test separately. However during the Integration phase all those components will be connected together, so that the work collectively appear as an enterprise solution. This is where the most Severe Technical Issues come in to surface.  The issues emerging up may be various and may result undesired outcomes in various terms, bugs, cycle time, look and feel, user friendlyness, etc etc. We would call them performance issues in General. When it is a bug, when it is a change in requirement, when it is an error - integration issue, at some cost as developers we have the confidence,  the things could sorted out some how within few days. But when actual end to end cycle time start to call for the challenge, we know that it is not easy as any thing else.  Even a well planned, and properly managed, Project goes smoothly till the last end. The projects will run – as planned, well with in buffers, according to the critical path or other triple constrain base lines we all agreed. But ultimately once the project is near to be delivered, reached this critical phase, during integration you will see crippled spikes of effort and cost variances are quite deviating than planned. Finally such integration issues generally contradict the performance expectations of client and would result very unpleasant experience.  

The project management knowledge and expertise on integration of software components are found to be very scarce perhaps. This knowledge is different from team to team – project to project, place to place, culture to culture, Technology to Technology. In Project Management perspective both Internal and External forces matter here. There is no wander, why that modern software is developed as components. To meet the deadlines, for future scalability and extensibility, easy to understand and maintain, help to deliver software fast, from the design – the Architects, and other various technical experts, will like to plan the software as distinguished components – so that they could be developed parallel and independently, may be which are scattered distributed in different computers for actual deployment. However once integrate only you will find the software is not performing up to the level of extend you have been thinking.What is the reason, how should you avoid this – in order to make sure a smooth integration.

The thousand probable technical reasons for this may be various. There can be communication deficiencies between different layers (Load balancing layer,  web layer app layer, etc), Middleware used generally need to be optimized considering various perspectives. There may be mechanical deficiencies, hardware deficiencies, scaling issues during the coupling of components. There may be batch processing issues. There may be streaming issues. There may be messaging issues. There may be other technologywise incompatibilities never identified at previous design phases.Various these issues, anomalies are hardly understood till the final phase of the project. Seeing various technical specs, following various standards only – doesn't actually ensure achieving the performance preferred as notes declared. The performance of an integrated system is always unique to the system and environment it has actually deployed on.

Therefore at the first place, during planning adequate buffer need to be in place for the actual integration and testing. Then;  for performance tuning. Even though if you find all the components are working fine, well tested before integration, after the integration only you will  see the integrated components are not performing  to the level of expectation, and giving bugs which never were observed before. Some very critical defects may be pop up during onsite deployment. Seeing these bugs, customer may too feel retarded and un-confident. Some times they may even reject the project and will proceed towards legal steps. This may loosen the future businesses and credibility. Greedy to make fast money, expecting a quick delivery - many project managers, shrink the deadlines, whilst creep the scope.

Therefore, understanding the real severity of proper integration, the project leadership specially need to be keen to avoid conflicts between different technical teams at integration. It is natural if they will start to blame each other team –delaying, arguing and worsening the situation. The technical leadership is criticized and blamed for improper design and planning, then their moral, may be dying at the most wanted time. Actually these issues are hard to tackle sometimes from the design only. Issues are realized only during the integration.  May be even only at deployment. Therefore leadership at the time of integration have to be very sensitive and well understood regarding the turbulent time arise unexpectedly at the integration phases. I have even observed, many lead profile sometimes tend to leave the projects, falling the issue into a further utter crisis. The replacement teams will therefore have to learn the premature software, code – which is not well documented, not adequately tested, not adequately maintained – hence perishing the situation, irritating the technical crowd.

Technically – at enterprise scale developments, we are observing that different vendor technologies are used at various levels of component communication. This happen during the middle of the development phase. As the vendors always want to change the requirement and bring additional functionalities. Since the business change fast, they would want to mount new features fast which were not in the scope during planning and designing stages. Such need of quick alterations during implementation will intrude unwanted heterogeneity and complexity to the systems. It is always best, well understood – if we can maintain a kind of homogeneous stature by default among the components.  For example you may find web services are both Synchronous, Asynchronous,  you may find different middle ware technologies are used between diverse components, you may find various technologies are used for XML parsing at different ends of the some product, you may find various versions of software 3^rd party libraries are used by different teams, etc. These silly and deliberate avoidable technical complexities and heterogeneous must be well identified during planning.  A proper communication workout plan needed to be enacted between the diverse teams. Otherwise it would be tricky and very time consuming to debug the multiple complexities and performance drops hence finding  the exact root cause at the integrated times.

The project management best practice in business should be to avoid such critical failures by tailoring existing process for software development and establish a mature Integration process to the Project Governance. This must always account the experience of previous projects and matured best practices with in the organization. Using this experience, existing resources, at the very initial stages of the project planning – the leadership team must tailor a well-defined integration process, along with the integration plan. It could be altered during the various stages of the software development life cycle. However – these process and plans need to be well communicated and sharply accommodated to all levels of technical team members at its very early stages. A good integration plan may include considerations, guidelines definitions and timelines considering Integration Sequence, integration environment, integration procedures, integration criteria, defining the build series etc. 


Above all, there is a huge responsibility for the marketing or business teams, who do talk the business, and finally making the agreements. There you must not give false promises to the client - specially in terms of cycle time of single operation. Generally the business discussions ends, with out quantifiable agreement on performance - per a single transaction. People forget performance during planning. But once the project start, developed and test, the performance come in to play. Performance must be given a priority, and performance expectation should be documented, once before the contracts are done. Such agreements should also incorporate fail in which terms. Other wise both customers, and develpers, going to pay for the hard life. The business relationships can be irritated and ultimately may end up courts - wasting time and good will.

What is Machine Learning and where would you need it?

This question have startled burning me quite often from the recent days. I have started to think where to put myself to be an early bird in era of time where people believe knowledge is power in any industry. If you just google machine learning, Google’s machine learning  algorithms will help you to find the perfect Matches for your intention to knowing what is absolutely machine learning is about. Google itself is lot about Supervised Learning and Unsupervised Learning according to some experts. How does Google's automatic news Clustering may work, How does Google find the actual matches, How does Google classify pages ... may be some foods for your thoughts. Hence Google is the Man, there should be no point for me copying and pasting the same on my page. Over the news I am seeing Andrew Ng – the famous celebrity Professor of Stanford for machine learning has become himself for list of 100 most influencing people in the recent Time Magazine ranks. One could argue that Andrew contribute enormous effort to Course ERA learning – creating a new age of distance learning. However I regard this may be just one evidence that the growth of demand for the SME (Subject Matter Expertise) for the Machine learning is in pace. We see communities are gathering up on this topic at exponential rates. Well, where should I place myself then?. Why should not I place an effort to get the pace of the knowledge that the emerging community have and become kind of an early bird? I should not further be a silent observer.  100 thoughts startled to pour in to my mind in a turbulent Bernoulie’s flow. Recalling past - there was a time where people thought Genetics will change the whole paradigm of world – there will never be a food scarcity ever going to come to earth. We could either develop one pumpkin to feed the whole world. :D. So – yes there is always hundred blown imaginations on an emerging engineering filed. Fortunately Genetics did not change the world as such.  Instead with time people have started hating genetically modified food. There I remember again another wave of fad – among the Engineering or Techy, community. They said Nano Technology will change the world. It does – yes to some far. But not as revolutionary as much like the IT or Telecommunication/computer science based industry and internet. Again people say it is quantum computers which will be most revolutionary hardware thing. For me even whatever we have for the moment as a processor is more than enough to do whatever we need to get done.  But what about the human greed.  We always want to have more, do more, eat more – so process even more.

Thinking about typical human thoughts based to endless greed, when there is something found – there is always a niche, who will want to produce things in mass scale – so economies of scale, good margins, through extreme sales.  Therefore whatever the thing you discover, this niche will want to have them in mass scale. So do Data. How do you process big data and other electronic information that is in web/cloud/enterprise or what so ever? Simple – How do you search the whole web on internet and find what exactly the best solution for an identified problem.  How do you find the precise knowledge that you need from a Sea of Knowledge around the globe. There may be million solutions or even more – for one issue from different perspective. Do you think that you have time and capacity to evaluate all the alternatives and critically analyzed and found out what is best? Probably this should be the area Machine learning is looking for. One would say it is BIG data.  But above analogy is partially about data, partially about a thing we don’t know. However the famous Gartner predicts that BIG data boom is going to be ended soon like the fads we discussed before.

But, think. People thought the computers will – replace the jobs and they will reduce the jobs. I don’t know whether that has been a reality.  Instead nowadays we see lot of people working on computers. People find jobs as computer programmers, maintainers, game developers, movie developers, teller machines, billing machines etc etc. That shows that people who have the knowledge on computer are still better benefited.  Therefore for machine language learners, there should be nothing to worry about getting the new skill ready. 

My thought is this emerging field will be better used to support decision making for big projects within very couple of years. There is big part of uncertainty always associated with any kind of  project from initiation phase to the project closer. You know what - big boys are what we think for now as they will never need big losses any more. The things would include effective risk assessment, risk prediction, making made or buy decisions, whatever evaluations of projects against the risk upon probable economic trends, finding the proper places, defining the best investment portfolios, share value predictions etc etc. I have seen the enterprise scale giants have Terra bites of storage for various information about there customers. How beneficial if they could effectually use them to identify specific customer segments and possible business niches which they could know in advance otherwise? Yes Machine learning programs may already been use them for now. However whatever the application, I see this is completely about new era of accurate predictions driven decision making in either projects, or at business in general.

So remember, Prepare Today.  Yes... The algorithms are going to be hard to remember. It may be lot of tough Math inside. There are mental Barriers to overcome. There you got to do a job as well. You have limited time. The knowledge is very rare. No one to support. You will need a GPU, or need to buy sophisticated hardware. Yes true– there may be 100 limitations. But If I don’t start developing my skill today – I will never get any other opportunity here again. I l just be another observer uneasily witnessing what others do right after few years. Do you want just to be no body observing what is happening by news at 8? If not – lets start with Course Era today. Those who know the rules will play better here.

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.