From Florian Mueck blog. Not a funny article, but a serious well structured and with clear points to extract from the movie character about decision taking and leadership.
I hope you enjoy it as much as I have.
Unlike other disciplines, software development products cannot be fully validated before they are built. When you design a building or a bridge, applying physical models and laws, it is possible to guarantee that the construction will not collapse under normal conditions and excluding construction issues like concrete composition or the design metrics not been respected. This allows to undertake very complex architectural projects that otherwise would be very risky to assume. In summary, because there is science behind, mankind has the means to achieve mastery in construction.
Software engineering has the aspirational objective of achieving this maturity but unfortunately it is not possible to create a model of what you are building without building it. The model itself, once finished becomes the deliverable. The closer comparison would be moving your software from your development environmet to your production environment, with any intermediate steps you may have (test,preproduction).
To overcome this, and provide the discipline with all kinds of warrants during every step of the implementation, software engineers have come out with a wide variety of models, principles and patterns that guide and inspire them throughout the process, bringing light to a task that otherwise would remain uncertain in terms of achieving its goal and mystical in the means that intervene.
Even when this is true, gurus, ideologist, visionary and Illuminati in the field have created a terminology to keep the knowledge in the initiated circle.
Hence, we have that OOP, a paradigm in itself, should be SOLID, while within our GRASP, DBT must be ACID what can be weird for newcomers. You better adjust yourself from the beginning being TDD and/or BDD, maybe modularizing following an AOP approach.
The list is endless even if we keep it limited to Programming paradigms. This doesn’t mean that the rest of science and engineering is free of paradigms that can not be elevated to the category of laws or theorems nor rejected as partial or wrong.
The future though is promising, if we observe scientific paradigms they are at the boundaries of the discipline. It´s not adventorous to consider paradigms progress pushers and hence responsible for any evolution.
The difference is that computer science is a relatively young discipline and paradigms outnumber theorems.
And while it could be contradictory, most of the theorems (Turing Completeness,P vs. NP,Halting Problem, Turing Test) are not relevant to the more daily tasks and problems a computer engineer may require, although some appear or should be considered more often than intruders in the profession may want to admit.
Also, efforts have been made to provide powerful tools for more regular programming tasks. Formal verification lies in this category, but reality is that we don’t see it used very often. Its complexity make it overwhelming for many tasks that would benefit from using it but it should still be kept in mind as a resource.
While computer science doesn’t reach maturity, paradigms are the crutches that help us get to our destination, the baby walker that guides our intuition and feeds our experience to achieve our goals in computer engineering and software development. They are our best option while the Vademecum for software development is not validated, approved and published.
It is difficult to disagree or agree but I would highlight this paragraph from the conclusions in the article:
In fact, using a model such as The Frog and the Octopus is an effective way to engage people infected with Agile Fever because it removes reference to Agile from the discussion of software development altogether. Instead of putting an infectee immediately on the defensive by suggesting, for example, that an Agile based software development process may not be the best fit, a better tactic is to discuss the applicability and value of adopting development strategies in a general sense. Those discussions might include considerations that are typically associated with Agile based processes such as requirements flexibility, schedule elasticity, extent of customer engagement, ability to co-locate the staff, and any other attributes that might be relevant to the program’s context.
As a developer I have never had that feeling of “this or that programming language or technology fits all needs” and as a project manager the homologous condition would be equally dangerous. Methodologies and processes are a reference that always must be adapted to the specific needs of a project and organization.
While reading on several topics to prepare for one of my next posts, I have found these two video jewels that I have enjoyed a lot. The joy comes from several aspects.
First, because they agree on some ideas that I had already drafted on my post, that is always something rewarding. We, human beings, like to find people who share our ideas no matter how crazy the idea is. In my case, even when I have been thinking on a new product or service and have found that somebody else had already developed it, after the first initial disappointment of not being so innovative, I have found myself very happy because the idea was worth enough so that other people was already working on it.
Second, because it has answered some questions that I also had on mind that were blocking me to develop some initiatives, in fact, even finishing the post itself. Hopefully, now I will make more progress.
The first video is about testing new products. Not only the keynote is delivered in a very entertaining way it is also very clear and well structured and with brilliant ideas and paradigms. I may say that it is kind of US centric in some aspects(you will understand when watching it), but except for that it is a ‘must see’ for any person considering to develop a new product/service in the Internet.
The second video, puts together several methodologies from different disciplines: Agile, Lean, new business creation and product definition are combined in a very natural way.
My conclusion, summarizing both videos, is:
The better your product is, the least mature it needs to be before being released because the most eager your users will be to enjoy it.
The conclusion can be more ellaborated but doing so would dillute the essential message, so I will explain it more in a future post.
In the last months, Prezi has become very trendy among tools for presentations. I hadn’t tried it and wanted to do so as I had heard so many things that made it very appealing. After my first 24 hours using the tool my perception even positive it´s not so ‘wow’ as I expected.
I have prepared a small presentation on a IT PM related topic, as what is my perspective on Information Technology as a ‘toy problem’. This is the result:
In any case, I don´t think any of them, nor Prezi solve the main limitations that I found:
On the positive side, Prezi helps to avoid adding too much text to the presentation, as it doesn’t look like a format where adding a lot of text makes sense. It emphasizes Zen style presentation what its not something to underestimate given the tendency to fill with text tens or hundreds of slides in PPT that has been suffered by many audiences along time. Sometimes it is required a change of environment, tool in this case, to overcome bad habits even when the previous tool could provide the same functionality.
In the process of preparing the former presentation, and others I am still working on, I have found other tools that I think can be very interesting, both of them have been for long available but I just got to know them now:
I hope they are as useful or at least entertaining to you as they have been to me.
And thanks to Panos for his great work and posts.. I have discovered a new dimension to WordPress…