What I learned this 2018

You never stop learning. Embrace learning new things. 2018 recap Machine learning Learning about Machine Learning had been a not-accomplished stepping stone in my career. Joining some Kaggle competitions and read other’s people code makes improves your abilities. Wonderful Sci-kit and pandas libraries make use of ML algorithms easy and neat. Ruby Having not used Ruby (albeit many years ago in my MRes. programme I programmed some basic scripts), it was funny to learn its peculiarities and of course, its dark corners. [Read More]

The value of open source software

I have some open source projects in my github account. Some of them are currently used by my ex-employer in several projects. Why should an organization have to open source some of its software? Let’s talk about it. Dissipating some doubts about software quality Having published your code in public allow many users to take a look to your code and (if it’s good) to dissipate its doubts about if it pays using it or not. [Read More]

To test or not to test

Introduction Some years ago I did not use any tests. We were cowboys in CodeWest where only fearful and strong people survive. Sometimes we tested some actions and assumed that everything else worked fine. But for the most part, code where developed almost like our sub-conscience dictated us what to type: we were guided by instinct. Of course, users of my applications were not so amused by this when they found software faulted and had to wait to me to repair it. [Read More]

Refactoring

Introduction Software is not a static element in a business. It evolves as business needs evolve. How can we make changes in software and keep high quality or, even better, not degrading it as we develop functionality? Refactoring Refactoring is the process of changing code structure for the better while keeping the same functionality. It should be a continuos activity made during software development, with the aim of easing maintainability of software. [Read More]

Waterfall process model is harmful

Introduction Waterfall model is a development process based on doing software development processes one after another and not looking back. Here is a simple diagram (from Waterfall model article in Wikipedia) of that model: Waterfall model That is it supposes we are infallible and the client is infallible so each phase is perfect and serves well enough the next. Issues with waterfall model Waterfall process model suffered a total criticism by Winston W. [Read More]

Project saboteurs

Introduction You have just been appointed leader of a new fascinating project. Hard years working in boring tasks have paid off. You are excited before your big day: your first meeting with your client (the owner of the business) and some other stakeholders (managers and other employees of the business). Sabotage So the meeting starts. Relationship with the business owner is smooth and you begin to write notes about software requirements, current system limitations, technologies… You know that you’ll have more than enough information to make the first requirement document. [Read More]

Self-improvement

The rules of the game have changed During many years, society expected you to graduate and find a job you kept until your retirement. Not many people changed jobs and only professions like medical doctors and lawyers keep studying and improving their skills. Now the rules of the game have changed and nobody expects that almost from any profession. Maybe you are a baker and expect to use the same ingredients and make the same bread over and over again, but your clients can change or acquire new tastes! [Read More]

Agile project management

Software Engineering is a special type of Engineering During too much time Software Engineering has been molded as a traditional Engineering, with the same terms and ideas that came from this disciplines. But they failed. Firstly, Software Engineering has an immaterial final product. It is not a bridge, a road, or a mine for example. Thus, software engineers works with ideas more than anything else. Thus, traditional engineers are limited by Physics laws while software engineers are only limited by the computational model they use and by the power of the machines their software run. [Read More]

Literate programming

Donald E. Knuth coined the term Literate programming in this paper he wrote almost 40 years ago. Knuth wrote a tool called WEB as a demonstration of what Literate Programming should be. This tool would understand Pascal and TeX code, using Pascal code to create a binary executable and using TeX code to compile its documentation file. Pascal code would be a bit different because of the use of predefined macros and it would be interleaved by TeX code describing what actions execute. [Read More]

Out of the tar pit

“Tar pit” is an idiom used since 1970s based on the similarity between software complexity and tar pits trapping engineers and animals (resp.). Out of the tar pit is a paper that analyzes the causes of this complexity and classifies it in several categories. The authors also analyzes the approaches that each type of programming technique uses to sove this complexity problem. But the most important contribution the authors do is giving a solution in the form of a new paradigm of computer programming. [Read More]