In the paper "Metaphor, myth, and mimicry: the bases of software engineering", Antony Bryant analyses the problematic around the term "software engineering", exposing and discussing multiple point of views from different recognised authors over the last years concerning what brings with (as unwanted baggage) the use of the status "engineering" in software.
Bryant opens his paper saying that in the 80s the term wasn't problematic at all and used to be a "good thing" but with the pass of time, the concept was transformed into more activities than just ordinary programming. The idea that software had to be "engineered" gave an image of rigour, care and assurance. However, soon began to be often misunderstood. In the late 90s, there was a consensus over the term within the academic and research community. Later discussions threads on the electronic list from the Conference of Professors and Heads of Computing produced and accepted what involves research, the study of computing, informatics, software engineering and other related terminology. Anyhow, the ones that were senior academic understood it but not the ones that were outside that domain such as practitioners, wider engineering communities, potential students and so on. In this point, is where Bryant sets the dilemma that software developers wants to imitate engineers and demand the status of an engineering discipline but commercial demands and consumer desires do not support this. Likewise, he suggests that maybe the term by itself adds extra complexity or confusion. This is where he wants to focus much more in depth in the rest of his work.
Looking much in depth the second section, the author tries to expose the distinct opinions of different authors about what software engineering is and fundamental key points to take into account. His goal is to reflect the ambiguity or unclearness of some ideas that still predominates over time caused by an emerging discipline that still needs to establish itself. Also, he strongly points out that terminology highly influence knowledge and the practice. [o] I think the terminology will always be an obstacle when it comes to the definition of software engineering. Consequently, the practice and domain will always be affected.
Moving on to the third section, Brooks's classic paper "No Silver Bullet" comes into consideration to depict the dilemma of software engineering. Moreover, in his work he expressed his worry about the use of construction metaphors in software engineering (also referring at this as the replacement of a metaphor by another) that derive in a powerful impact on people's practices and cognition. From this, maybe the term "software engineering" itself its constraining rather helping in software development. At the end, the author of this paper poses the idea of rejecting metaphors altogether or at least admit the side effects of them. In my opinion, trying to eliminate all the existent metaphors can have serious drawbacks. People are used to them, they feel comfortable with them and literature from many years ago use it. Additionally, there will be cases where people will refuse in changing their way of thinking. Thus, the only suitable choice is admitting the drawbacks and live with them. Maybe, as an extreme idea, we could create new metaphors but again we will come again to the starting point of the discussion.
In order to analyse and dismantle the engineering metaphor for software development, the author presents two examples. The first one, IT, illustrates how terminology generates a barrier for understanding what the term means. For instance, causing people erroneously apply for a job in IT or not applying to it. Frankly, I still have doubts about the definition of the term and I have always seen as clear example of how a word can blur a job or area.
The second one, requirements, is much more critical to software development practices. There is a general idea that requirements phase is seen as the most important and most difficult phase. Furthermore, the term "requirements engineering", is associated to activities that lead to the creation of the products of these phase. The terminology surrounding requirements for computer-based systems is replete with references to the engineering metaphor. Similarly, the idea that a good requirement specification should be clear, concise, concrete, and so on. Moreover, the assumption is that the requirement process must be systematic with some elements of formality and management. Bryant states that although the engineering metaphor provides a useful basis it's partially correct, arguing that it might obscure key features of the process.
I partially agree with Bryant in saying that metaphors hide or blur key aspects, but the reality also indicates that they also form a basic human mechanism to transform or interpret complex ideas or concepts in a more humane way. Personally, I don't think that metaphors obscure essential aspects if they are handled correctly.
Also, to depict how communication can have a big impact in the interpretation of the ideas, the author explains the conduit metaphor. The underlying concept of the conduit metaphor is that the information is transferred from one point or person to another. Good communication flows without blockages and good reception involves extraction and unwrapping it.
From my point of view, failure in the communication within all the parts involved is due a series of factors. As Davis stated paraphrasing Demarco, anyone involved in requirements should have strong human skills, communication skills, feeling skills and listening skills. Moreover, communication will fail without applying the proper effort. That is why I think that should be encouraged from the very first time.
Finally, the paper ends suggesting that the engineering metaphor moved us forward in the activity of developing a discipline for software development. I could not agree more with his statement. Personally, I believe that even though we are not seeing clearly where are we going or from where are we coming eventually we will find the appropriate foundation. Logically more discussions and new points of view will arise making us reformulate theory and concepts.
Feb 23, 2014
Feb 17, 2014
Latency is inevitable with today’s internet architecture so InstantClick cheats by preloading links you are likely to click on.
Before visitors click on a link, they hover over that link. Between these two events, 200 ms to 300 ms usually pass by. InstantClick makes use of that time to preload the page, so that the page is already there when you click.
If you want your website to not be flooded by requests, you can set a delay before preloading starts when users hover a link. It will still feel instant.
If you don’t want any wasted request, you may preload on mousedown.