Here’s an article of why I think blogging is important and a great tool for everyone.

What are the benefits of blogging?

First and foremost, I want to start by saying that language is what allowed humans to evolve and begin to share complex ideas with each other. The written word allowed us to reach massive audiences never known before.

If you think of it, language is like black magic, you can plant ideas into someone else’s mind by just talking to them or in this case, writing and them reading your words.A permanent place in their brain.

With the technology evolving rapidly, it was just a matter of time for it to become a household commodity. At least in developed nations I mean.

This allows people to reach into the remote corners of the world in an extremely fast way and without the economical, time or technology constraints from even 50 years ago.

However, with the new technology, new ways of communication also opened up, which want to control how and who we can communicate to over the internet. This is of course social media.

Every person needs to have a voice, either online or offline, to share his ideas. Good or bad. Recently there has been an uptick for the control of the internet and change it from it’s original de-centralized nature, to a locked down, centrally administrated one.

Having your own blog or website prevents you from losing your voice in case Twitter or Facebook decides you’re not worthy for their platforms. Having a place you can control yourself on the internet may seem like a technological feat but it’s now easier than ever and extremely cheap.Just skip on one or two cups of java brew from the Seattle-based green mermaid chain.

More people should do it.

These are two processes within the software development lifecycle. They may sound similar but have different direct objectives but ultimately, relates to building a system that meets the customer’s needs.

What is verification?

A review to verify that a step or a components is within it’s own spec.

You could say it as per the source below: Are we building the product right?

What is validation?

A review to validate that the product or delivery as a whole, meets what the customer needs.

You could say it as: Are we building the right product?

The former is a low level operation and the latter is a high level one.

https://giphy.com/gifs/l0HlTdK9f97qfOGRy/html5

 

via GIPHY

 

Sources:

Verification vs Validation

Agile is a methodology for software development that has become extremely popular since the new millennia. It was published as the Agile Manifesto in 2001 by 17 software engineers that gathered in Snowbird, Utah.

It has a stark contrast to the waterfall development model, where there after everything has been planned, it cannot change until the end or can do so at a very high cost.

Agile embraces change. One of the principles of Agile is to have sprints, or small windows (usually few weeks) to implement a specific feature of the system. After the sprint has started, nothing can be changed. After it ends, it can change if there’s a high priority item. Waterfall would usually take months for a change to be implemented as it would require additional planning and considerations.

As we have mentioned before, change is essential in software development and as such, a methodology that embraces it allows us to deliver better products for our users.

How it compares to OO?

Well, true Object oriented programming allows for fast changes in the code. With a high cohesion, delegation of functionality and encapsulation of objects, you don’t need to rewrite everything in the system, only the components that would be affected directly by the change.

Here’s a video that talks more about it:

Sources:

Ken’s blog at https://kenscourses.com/tc101fall2016/syndicated/object-oriented-and-agile/
http://www.drdobbs.com/architecture-and-design/oo-as-a-prerequisite-to-agile/240164883
http://www.walterbodwell.com/drupal/node/7
https://en.wikipedia.org/wiki/Agile_software_development#History

TDD is pretty well known in the software industry.

What is exactly TDD? It is a software development process where testing is added at every step to fix bugs faster.

On a standard process, testing is left until the end, when development of the main functionality has ended and the QA (Quality assurance) team is tasked with testing it and finding any abnormal behavior. This can lead to longer development times or extended costs due to bug fixing.

A great addition of TDD is unit testing. Small tests verify a single functionality of the code for predefined responses or answers. This allows a faster reaction when there’s an unexpected bug or when previously working code was updated and it stopped working, ie a regression.

Unit testing can be added to a manual process or currently there’s automated tools that run a whole suite of tests on every software release or build.

TDD ensures a better code quality overall since it has more strict quality controls.

 

Sources:

https://hackernoon.com/introduction-to-test-driven-development-tdd-61a13bc92d92?gi=cabc315fd410

Test-Driven Development (TDD) – Quick Guide

https://blog.bitsrc.io/a-guide-to-test-driven-development-tdd-shorter-feedback-loop-faster-workflow-ce5bd6b247c4

What is code revision?

Most of us get a headache when our code doesn’t work, doesn’t compile, throws errors, etc. When it’s finally fixed, it’s a relief. We move on to the next thing in our checklist to make or fix.

However even if our code works, we may need to go back to it time to time. Specially if it’s really old code.

Code revision allows us some introspective to old us and how we coded before.  Since we are getting better, we can see our earlier flaws better than when we were in the moment writing that code. If the time allows, we can even refactor it to have it have better readability or easier to maintain or add comments if it requires it.

Not only we can review our own code but also our coworkers. What we might miss or think it’s good enough, could be improved or changed if a more knowledgeable person helps. This can provide us great insight and new perspectives into our own code and ultimately make us better developers.

As mentioned in my post on Modeling Languages, UML is one of the most popular and most used in software development. UML stands for Unified Modeling Language. It’s called Unified because it was a combination of several.

UML can be used in a variety of diagrams to express functionality.

• Secuence Diagrams
• Class Diagrams
• Object Diagrams

Sequence diagrams are utilized to describe the processes within a system. The communication between its components. If we are talking in software development, specifically in Object Oriented Programming, the communication would be messages sent between objects which would cause a behavioral change.

 

Class diagrams in UML are utilized to describe the name, attribute (values or data) and behavior (methods) of a class.

 

Finally, the object diagram is used to represent hierarchy ob objects when using inheritance.

 

To recap, depending on what is being represented, one diagram may be suitable over the other. If the customer wants to view functionality, creation or hierarchy within the system.

Sources:
https://www.lucidchart.com/pages/uml-sequence-diagram
https://www.ibm.com/developerworks/rational/library/3101.html
https://www.uml-diagrams.org/sequence-diagrams.html
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-diagram/

What is a design pattern?

As I mentioned in one previous blog post, we need to save time and money to on risk factors to really focus on the work that matters.

The gang of four, Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm, released the now renowed book Design Patterns: Elements of Reusable Object-Oriented Software.

Design patterns are common solutions to common problems. They focus on what, not how. This means they are language agnostic. One additional benefit they provided is that the communication between developers on different language and companies, can understand each other clearly when using these patterns.

The patterns fall into 3 main categories.

• Behavioral
• Creational
• Structural

Behavioral patterns refer as their name implies, on behavior. How objects interact with each other. Sending messages, calling methods or extending functionality.

Creational patterns focus on creating objects. Things like how are they created, how many are created or how are they prototyped.

Structural patterns belong to the structure of the objects, like hierarchies and on the proxy pattern, where one communicates messages as a proxy to the real one.

Some are really easy to understand like the Singleton and Proxy, others are more complex like Flyweight and Decorator.

Sources:
http://geekswithblogs.net/subodhnpushpak/archive/2009/09/18/the-23-gang-of-four-design-patterns-.-revisited.aspx
http://www.blackwasp.co.uk/gofpatterns.aspx
View at Medium.com

 

How can we define the core functionality of a software system in a clear and user friendly way.

While they are a great tool to have a common overview of the system to be developed, one should not go and obtain use cases in every single scenario that could happen, even the extremely unlikely ones, as that costs time and money. They define the scope of what the software should do.

Use cases are obtain during the requirement gathering process and planning phase.

A great tool as well are user stories, which helps us understand in what way the target user will use it (duh) and to achieve what objective. There may be several types of users, each with different use cases.

happy user because the app works correctly

According to the top Google result, The Unified Software Development Process or Unified Process is an iterative and incremental software development process framework. [excerpt from Wikipedia].

What is that you might ask? It’s a way of working. The most well known is RUP or Rational Unified Process, developed by the company Rational in 1996.

It has 3 main pillars:

• Iterative development
• Use case driven
• Architecture centric.

The whole framework is designed to make planning for software development faster.

It provides a template to divide the work into 4 phases, which are inception, elaboration, construction and transition.

Inception is the first step, where everything beings. From budget assignment, feature lists, use cases, schedules and responsibilities.

Elaboration refers to more detailed information or you could say, project specifics. Features, requirements, technologies to be used, how basically.

Construction is self explanatory. This is where code actually is made, every feature will be implemented during the development sprint.

Transition is where the software gets delivered to the customer initially or revisions that can include bug fixes or additional features.

Here’s a detailed explanation:

Sources:

http://wiki.c2.com/?UnifiedSoftwareDevelopmentProcess

https://en.wikipedia.org/wiki/Rational_Unified_Process

 

 

Final topic we have from this peculiar book.

We know basically everything now on how to create babies, I mean, software. How does its life looks like?

Treat them with care. Photo by Ryan & Dana on Flickr

It has the following sections according to the book

• Feature List
• Use Case Diagrams
• Break up the Problem
• Requirement
• Domain Analysis
• Preliminary design.
• Implementation
• Delivery

Going back to the baby analogy. We can compare it in such way that our software is like this:

1. Planned (No happy accidents!)
2. We had decided how it would be named
3. How it will be raised
4. Setting house rules on what it should and shouldn’t do
5. Develop a good base so when it’s a teenager, it’s not a nightmare to everyone else it communicates to.
6. If everything is done correctly, you will have a happy and productive adult ready to help everyone.

Practice makes perfect!

Thankfully, software development doesn’t take 18 years but may be as expensive or even more so!

There are lots of tools, methodologies and ways to do things. I believe that while you can learn most from a book, real life experience is the best teacher.

Iterate on each software project to be better and risk will be reduced immensely. You will also get paid a lot. Basically a win/win.

Somewhere I read something along the lines of:

Everything that can be measured can be managed. If it can be managed, it can be improved.

Which I would say relates pretty good to the contents of this book.

Hasta aqui mi reporte joaquin.