Friday, July 10, 2015

What is the Future of Software Engineering?

As more people are born into this technology-centered world, coding, and use of technology will become a fundamental skill today.

The twentieth century had a new science - Computer Science. In searching for the scientific basis of Software Engineering, Computer Science has been seriously attempted. The computation was to become one of the most important disciplines of the sciences. This is because it is the science of how machines can be made to carry out intellectual processes and capabilities. We know that any intellectual process can be carried out mechanically and performed by a general-purpose digital computer. Business starts to think intellectually, with value delivered continuously.

Software engineering is a branch of computer science which is a branch of mathematics. So engineering is the practical application of principles and practices constrained by the laws of the domain. Software engineering with about half-century history is still a young discipline. Current agile movement is simply a reverse of its evolution from its scientific phase back to the artistic stage, but with a higher level of maturity. The difference between engineering as art and engineering as science is that objectiveness of requirements/design specification. With engineering as science, different people specify requirements/design you get the same results, and different people read the resulting specifications you get the same explanation. With engineering as art, the more people specify, the more versions you get. Once written, the more people read it, the more explanations you get. This is because both specification and explanation are based on science for mature engineering while they are based on opinions for immature engineering. But at the high mature level, the scientific side of engineering is for automation, reliability, and continuity; and the artistic side of engineering is about imagination, innovation, and invention, etc.

What is the future of Software Engineering? Some say, “Software is eating the world.” The answer is in the history of engineering where you can see mature fundamentals of design common to all engineering, the concept of engineering science, and how engineering science is emerged by solving theoretical problems (the roots of practical problems) for each engineering branch. If we do not learn from history, we will repeat it. The future of the IT industry is on higher and higher levels of development and increasing stratification of code, vs middleware vs end-user developed packages. Many predict that the applications we work on will:
-Be more user-centric, the user will do the programming and the programmer will build the systems and infrastructure to enable this.
-Applications will become more interrelated as we move to a world of systems-of-systems where constraints govern how and what we develop.
-Machines, tools, and environments that programmers use will become more powerful, easy-to-use and knowledge-base.

Agile is emerged as a major principle and methodology to manage software development.
Life of IT is made considerably easier as there is no need to make Agile work in a Waterfall thinking world. Agile is about adapting to a rapidly changing context, including requirements. If your problem domain does not suffer from such changes, then you can imagine that "engineering" the requirements is a perfectly good way to proceed. But, the problem is changing. So instead of natural selection, how about adaptation. Methods need to grow and adapt to address the problem at hand. So agile in the future, will have to change to address other changes like constraint-driven programming, etc. What this means to the Agile manifesto is that you will need a way to synchronize multi-level, interdependent groups of development. Agile is a fantastic single team development model, but it does not provide enough guidance for large software initiatives involving several development teams, sometimes at different levels of the coding schema. So the next thing for Agile is to scale up and to make this culture change stick. Addressing enterprise behaviors and moving to an outcome-focused, outside-in organization; leaders act as coaches and applying new technology and innovative ideas to the way of working as soon as they stay ahead of their competitors, and have fun doing it.

Being customer centric is key.  If the notion of "customer-focused development" is the successor of Agile, and then most of the organizations fail miserably at being agile. That is, agile development is (or at least should be) client focused at its core. That's the whole point of short iterations, etc. Put another way, if you're not already client focused, you're not agile. From IT management perspective, when it comes to Enterprise IT, optimizing coding has huge economies in time, testing, tuning, re-working, integration etc. generally IT leaders want fewer software platforms and the ones they invest in, they want to adapt over time without frictional IT costs. They don't want to build themselves into a corner with coded proprietary solutions or have to glue many different software tools together that each cost time and money to maintain and support. This is what agile development is about - embedding software app authoring and iteration skills into change teams so that companies can continue to evolve their ideas and processes without any frictional IT cost. Also, you need to incorporate Outcome-Driven Innovation (ODI) into the codeless agile methods and enable customers to participate in workshops to develop applications 'across the desk' by removing coding from the applications authoring process. ODI recognizes that customers don't always know how to articulate the outcomes they seek (and how unmet needs translate into applications designs). ODI enables the emotion to be removed from prioritizing unmet needs, that's why so many innovation experts encourage its application in product innovation methods. Agile needs to be made successful with all those aspects that challenge / contradict the manifesto. That said, the complexity of making agile work bring yet new twists. For starter, building for sustainable, evolutionary architectures so they are always fit for purpose and never require re-platforming projects without delivering business value. Hence, before thinking beyond Agile, there is still much pondering how you make Agile work well, such as multi-interdependent workflow, fix time delivery, fixed scope or fixed objectives, distributed delivery with travel limitations. That's the reality that many business stakeholders impose.

As more people are born into our technology-centered world, coding, and use of technology will become a fundamental skill in much the same way the math works today. This is combined with the simplification of programming tools and proliferation of “DIY” - doing it yourself interfaces, we will see the product owners become self-sufficient and able to execute their vision of the project nearly immediately and without the specialization of an IT Department. Additionally, crowdsourcing is a fast growing segment since last decade. This now introduces the concept of external development teams as a possible source for code segments which can be incorporated into the finished design. Agile provides limited guidance on capitalizing or managing these new resources.

The software is eating the word, Software Engineering is no longer just an isolated discipline only a few geeks work on it, but a common practice everyone has the chance to play around it, it has permeated into every business in every location, and it underpins the business capability and brand of every digital organization today.


Good day, just recently I came across a good site that helped me to successfully start in business. An offshore development center is a relationship that brings lasting benefits. By ordering for migration from classic to lightning, you will be sure of a professional service. Their team from Ukraine helped me create a good business. I recommend this site to everyone.

There is a lot of tension between people and organizations who are quick to adapt to change and those who choose not to. A good example is the difficulty of software developers trying to accommodate change while adhering to the fixed structure of a software development specification contract. In this regard, I trust the service

Post a Comment