The Software Engineering Sand Clock

Once upon a time, during the late 1950s, large computers became available to research institutions and universities, now on the hands of the public domain, their use and programming became an activity of many and a new profession was born – Software Engineering, although, it wasn’t officially called that until a NATO conference took place during the software crisis in 1968 where the difficultities and pitfalls of designing complex systems were discussed.

Programming languages were created as formal notions to replace and facilitate the complex mathematical formula based instruction code and as computing capacity and the demands grew, better programming languages, tools and automation were sought, leading to the emergence of a new discipline – Computer Science/Informatics.

In 1963 the first time-sharing system appeared as a transition from batch processing and interactivity was back on the game, but this transition was a slow and complex process that brought big companies to the brink of collapse. This is when the baptizing conference of NATO took action and this difficultities were openly discussed with an unsusual frankness.

Between 1965 and 1966,  academics such as Dijkstra and Hoare wrote about data structuring and harmonious cooperating processes. Their ideas had a profound influence on new programming languages, known as structured.

Difficultities were still far from dispelling, so a conference was convened in 1968 to find a solution. They produced a report that defined the foundations of software enineering, based on the best practices of project management and production already used in traditional engineering disciplines.

Dijkstra’s structured programming, declaring programming as a discipline in contrast to a craft. They appear to have succumbed to the trendy yearning for continual innovation, and to have lost sight of the need for careful craftsmanship. enable us to create artefacts that we can show and be proud of.

sand-clock
Image source: Cliparts.co

Software development’s cover of The circle of life.

Nants ingonyama bagithi Babaaaaaa~  Sithi uhmmmm ingonyama (ingonyamaaaa)~

circle_of_no_by_tsaoshin-d6h8pug
Illustration by TsaoShin

No? Well alright, lets get serious.

SDLC or software development lifecycle is a series of steps or phases, that provide a model for the development, acquisition and configuration of software systems.

The methodologies can vary across industries and organizations, but  there are standarization such as ISO/IEC 12207 represent processes that establish a lifecycle for software, and provide a mode for the development, acquisition and configuration of software systems.

Steps are usually as follows:

software-development-life-cycle

There are two different types of SDLC that can be used: waterfall and agile.

The major difference between them is that the waterfall process is more traditional and begins with a well thought-out plan and defined set of requirements, whereas agile SDLC begins with less stringent guidelines and then makes adjustments as needed throughout the process, making it well suited for applications that are updated frequently.

Resources: VERACODE


Being “Agile” while developing software

There is an umbrella term for a set of methods and practices that are based on values and principles, expressed in the Agile Manifesto, that you will get to know in a bit. It is known as

ASD

The 12 principles that define it are:

  1. The priority is to satisfy the customer.
  2. Welcome changing requirements for the customer’s competitive advantage.
  3. Deliver working software with preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Motivate the individuals that build the projects.
  6. Promote face-to-face conversation and sustainable development.
  7. Working software is the primary measure of progress.
  8. Agile processes promote interaction between sponsors, developers and users.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity.
  11. Best works come from self-organizing teams.
  12. The team becomes more effective and adjusts its behaviour.

There are also several agile project management frameworks such as:

descarga

But it isn’t only rainbows, order and friendly team work, there are some other downsides. You can find more about it HERE

Team:

Victor Najar  & Carmina Pérez


Inside the mind of a moral Software Engineer

Engineering Ethics is the set of rules and guidelines that engineers adhere to as a moral obligation to their profession and to the world.

There is a code of Ethics and Professional Practice established by the Association for Computing Machinery (ACM) and it involves 8 major points.

14060030_1250162878340757_249038050_o

  1. PUBLIC: Computers have a central and growing role in a lot of manners, so it has the power to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. So we need to have the user in our thoughts, and take full responsibility for the work we do.
  2. CLIENT AND EMPLOYER:Software Engineer needs to be fair with the client, considering the interests of the customer in the best way, without taking the advantage of the situation.
  3. PRODUCT:Software Engineers must ensure that their products are completely qualified to be sold. Also, they need to be sure that their product is complete, clean and legal. Basically, the Software Engineer must ensure that the final product follows all the professional standards.
  4. JUDGMENT:Software engineers shall maintain integrity and independence in their professional judgement.
  5. MANAGEMENT:Promotion of ethical approaches to the management of software and maintenance should always be present. Effective procedures, standard based software releases and fair remuneration are some of the key elements when managing software.
  6. PROFESSION:Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
  7. COLLEAGUES:Fair and supportive communication among colleagues should always exist. Also, assisting colleagues on being fully aware of current standard work should be present.
  8. SELF: Software engineering should always be used to improve the way a professional furthers their knowledge on developments in the analysis, and improve the ability to create safe, and easy to understand
    Continue reading "Inside the mind of a moral Software Engineer"

Alice in Software Engineeringland

Let me tell you why you are here: you are here because you know something. What you know, you can’t explain but you feel it, you felt it your entire life.

It is this feeling that has brought you to me, do you know what I am talking about? – Yes, software engineering-.

Do you know what it is? -Software Engineering is everywhere, it is all around us, even now behind this very screen.

–Serious definition and stuff–

Unfortunately no one can be accurately told what software engineering is, you have to see it for your self, this is your last chance.

You take the close-tab pill, the story ends. You keep scrolling through social media and believe whatever you want to believe. You take the TC1019 pill, you stay in Software Engineeringland, and I show you how deep the rabbit hole goes.

matrix_065pyxurz