Category Archives: software engineering

Inspiring quotes on computing

“It is not only the violin that shapes the violinist, we are all shaped by the tools we train ourselves to use, and in this respect programming languages have a devious influence: they shape our thinking habits.”
Edsger W. Dijkstra
“Program testing can be used to show the presence of bugs, but never to show their absence!”
Edsger W. Dijkstra

388 total views, 1 views today

Streamlining Software Development Projects

In most developing countries the software development discipline is emerging. Several private and government entities are in the process of automating different business activities. Just like the software discipline itself, the information technology professional are still gaining expertise in specification and verification of software solutions.Where the clients know what they want, they are not in position to explain it to the developers. And equally less experienced developers find it a challenge to understand the needs of the client.

To overcome this problem, some entities hire a consultant to help manage and supervise the implementation process. That is, there are two different consulting firms involved in the project – one to do the actual implementation and the other to supervise the implementation. They all work for the client, but the supervising firm ensures quality is delivered.

This approach of a supervisor and the contractor is well tested in civil engineering works. Where you will find, the main contractor, the supervisor as independent contractors.

For this work, the discipline has to be mature such that the approaches and documentation are well understood by the different parties in the project. In some projects, this has improved the quality of the project because each contractor has a specific responsibility.

I have seen this approach work in software development with amazing results. Usually the supervising contractor requires domain knowledge to ensure that the engineering product serves the desired purpose. The presence of supervising contractor implies the need for proper specification, documentation and reports because these are part of the main inputs for the supervising contractor. The mandatory need for these documents guarantees a level of a streamlined the software development process.

995 total views, no views today

Microservices is not more than a specialized case of SOA

Over the last couple of years, there has been renewed energy in the subject of service oriented architectures. The invention of term ‘micro services’ has warranted a immense interest in the subject of service oriented architectures.

Despite the initial contention on the difference between SOA and the already mature Component Based Software Engineering (CBSE), there is consensus that SOA improves the key attributes of software such as agility, cost to market, flexibility, inter-operability and many others. A service in SOA is now understood as an autonomous software unit that can be used programmatically across the network. Services can interact regardless of the underlying technologies for as long they expose their interfaces for use by other entities.

The size of a service — how much functionality can be bundled into a single service unit is a issue of design left to programmers and software architects. Of course services are compositional – i.e. two or more services may be combined into a new service in its own right. Practice and programmatic recommendations suggest that a service should bundle a business functionality. And SOA in is traditional form has been largely conceived to be applicable at the business level.

Microservice advocate a new way of building systems with more fine grained service units. Simple low-level core functionality can now be exposed as services for use in building high-level systems. A micro service may be as large as a function in a functional language or method in Object oriented Language. Microservices should not be equated to functions or methods because a service is an architectural unit.

Whereas micro services raise the level of flexibility, they increase the number of ‘moving’ parts – each service is autonomous, deployeable in an independent process. This comes with well known challenges of distributed computing. Obviously we have come to learn that in software architecture there is need for trade-offs. It may be very hard to optimize both flexibility and reliability.

The level of granuality and new usage scenarios for microservices, require new support tools for designing, monitoring, provisioning, management of microservice based systems.

2,392 total views, 2 views today

What About Sub-standard Software Systems

Like any incurable disease it (software) attracts more quarks, magicians and fortune tellers – -E.W. Dijkstra

In the past five years, I have come to think that it is valuable for the general public to know the distinction between a good computer system and a bad one, especially that the consequences affect even the innocent. Perhaps you have been to the bank and a teller casually announces that you can not withdraw or deposit money because the system is ‘down’, or you can not access your academic transcript because the system is ‘unavailable’. Maybe you have ever missed salary because of the computer system! Failure to withdraw your money may mean the landlord evicts you from the house or your son misses school. Failure to get the transcript may mean a missed life-time opportunity.

Such systems lead to wastage of millions of money, put lives at stake and businesses on the mercy of quarks. For government, the security of nation can be put at stake. The more computer systems fail, the more it becomes incurable because the general public has come to believe that it normal for systems to usually fail

A comparison with civil works

A comparison between the engineering of computer systems and civil engineering is informative. Unlike civil works, where the effects of a rudimentary engineering or lack of it are there to see through collapsing buildings, eroded fences and roadworks that are often fatal and lead to deaths, the effects of a rudimentary computer system are not readily visible. Mechanical engineers can get away with approximations for unknown or incalculable effects, substandard materials, and other surprises by building in safety margins. However, in software systems a single bit error can have disastrous consequences. Despite the the invisible nature of immeidate impacts of ill designed computer systems, the consequences  go beyond what most can predict and can be as fatal as a collapsing building with occupants.

Unlike civil works that may be faced with fake construction materials (such as cemment in Uganda), the key players in the construction of software systems are the programmers and those that buy the software. So the quality of the software is enitely in the hands of programmers.

Now warrant not guarantee -“as is”

 Interestingly, computer scientists mastered in advance, the art of hiding their incompetencies. They use fancy terms such as bugs to describe what ordinary means a malfunction. That is, a system that can not correctly do what it was intended to do. They do not even want to take responsibility of their own actions. Most software systems provide no guarantee or warrant for even the very mission the system is supposed to achieve.

The public has also accepted this situation and with not regret, it is not is common to hear  with a smile  that the computer system is not working, or the computer system is unavailable. Such lame explanations that have made system failure synonymous with the computing discipline are hurting. Such systems should not be casually accepted and need to be questioned for evidence of rigorous software engineering in the design and construction.

Good software is supposed to be reliable

Like any tool, a good software system is supposed to be reliable, that is safe to use by virtue of the fact that, when used, it acts as intended, or, more precisely, it reacts upon our inputs as intended. Even before subjecting a software system to a rigorous check for suitability of purpose, some indicator of incomplete and poor workmanship are usually there for even the computer illiterate to see. The first systems to be dismissed with contempt are those that fail due to any user inputs or limit existing good manual practices. That is, start by entering any data and good system should continue to behave normally. Bad systems will fail. Such systems are a clear manifestation of inept software engineering where the system is erected prematurely.

The buyer  at fault 

Executives, procurement officers should be aware that any programmer of some intelligence can cook up a computer system, the properties of which are utterly unattractive and unrelated to anything else. They need to be aware that the construction of computer systems is not a chaotic process with out systematic means to evaluate and sort them.

The executive managers with no formal training in software engineering approve these systems on the basis of their computer literacy normally in typing skills and email forwarding. Simple clicks and intelligent animations are usually enough to   append their signatures on products that are an art of ingenious and intelligent computer quarks.

Software production is a systematic process and quality can be assured

The most important aspect of a software-based system lie in the modeling and analysis of its interactions with external factors and overall mission assurance. Before purchasing or accepting to use a software system, it must be checked for for system-level information assurance issues. It must be checked for Possible fail-stop mechanisms and procedures, fallback, contingency solutions for both direct and secondary effects of failure modes. And Usage scenarios are frequently not a priori limited.

The regular failure and unavailability of computer systems has convinced the general public that it is normal for computer systems to fail. The proliferation of poor systems is a making of buyers who are easilty decieved by self made computer experts. As Edgar Dijkstra put it, Like any incurable disease it (software) attracts more quarks, magicians and fortune tellers

2,442 total views, no views today

Benefits And Advantages of Webservices

To begin with there has been considerable attention to web services  in the last couple of years since early 2000. For starters  web service are no more that applications that are designed to be used across the web. Web services provide a program-to-program programming model where one service invokes another using web standards including the well known HTTP and XML. Here I outline the main benefits, some technical others business.

  1. Interoperability – when faced with a challenge varying systems architectures, legacy  systems, a cocktail of programming languages that make up systems that make up systems which need to be integrated then web services come in handy. Perhaps the most important benefit of web services they provide a non proprietary means of interactions. Web services only need to speak the same message protocol for them to inter-operate. So far a common set of standards-based communications method that include HTTP, WSDL, SOAP have been developed. These make it possible for web services to be platform-independent.
  2. Usability – web services are designed to be used over the web, that is just in the same way a page is fetched, one can fetch web services capability over the web. The capability of a web services varies from simple information lookup to complex algorithmic computations. Therefore when a service is used to expose a business logic, then it can easily used.
  3. Re-usability – Web Services are designed to be combined to deliver more added value services. Web services serve as building blocks and this makes it easy to reuse Web Service components as appropriate in other services. Also legacy applications can be wrapped into web services for use by others
  4. Deploy ability – Web Services are deployed over standard Internet technologies. For instance using Apache, Axis2 to provide HTTP, WSDL driven services. This makes it simple to deploy
  5. Agility – this looks at ability to change. When a an enterprise IT infrastructure is streamlined into services, new functionality to address new business demands is a matter of assembling existing services. Of course a few more services may need to build, but overall it is easier that re-building a new system from scratch.
  6. Quality – Related to reuse, because web service development approaches allows services to be built by assembling existing existing services, it logical to expect that such services are already tested with known performance characteristics. Therefore new systems will be less buggy.
  7. Cost – The cost of developing new systems reduces significantly since such systems are assembled from ready made web services. Such cost reductions translate into profits on may be passed on the customers. The customers stand to win from cost cuts and efficiency brought in by web service

Overall, an enterprise that streamlines its operations into web services stands to benefit in many aspects.

2,707 total views, no views today