So we have come nearly full circle here. Our focus is going back to where we started, the customer. We have learned most of what is needed for good software development, what now?

We need to show the customer we are good for them. That we understand their needs and most importantly, we will deliver.

To deliver, there are several ways to achieve that. We can use two main development methodologies. Each has its pros and cons.

The first one is feature driven developments.

It’s not a bug, it’s a feature!

via GIPHY

 

So, while we are not going to build a bee hive, it’s important to have defined what will be built and in which priority. This goes back again to reducing risk, which we talked about earlier.

We iterate over the list of features, one at the time, until the system is complete. Here the functionality of the system is defined on its intended objective.

The second one is use case driven development.

Here the functionality is defined from a user’s perspective and how are they going to use the system for their work or objectives.

Neither has technical details.

The use of each one depends on the customer context and the specific needs of them. This also involves the correct planning to determine which one is the best one for any given project.

An excellent practice is to have unit tests. Which are small tests, although several, that verify the correct functionality of every part of the system that we are making. To ensure that any new code change doesn’t break it or that it delivers the expected output. They are a central part of Test Driven Development where testing is included at every step instead of at the end as part of the QA process. This ensures a superior quality and lower bug fixing costs.

Again, you can find my alternate post on this here:
https://davidtc2004.wordpress.com/2018/11/22/if-it-works-break-it/

Smash yo code kids

Continuing at the cliffhanger of the last post, we need good design. How do we do that?

First, budgets. Budgets have two main constraints upon any project, time and money.

In order to minimize Risk (you remember RISK don’t you?), the useless needs to be avoided.

Why waste time and or money solving a problem someone else already did? There are a set of common solutions called design principles.

They help us write quality code.

The first one is Open-Closed Principle. The focus here is that an object or class allows different functionality to be added to it but not directly, instead it is added through extension in a subclass. That modified behavior would only be added to the subclass and not to the parent’s core functionality.

The second principle is Don’t Repeat Yourself principle.

This goes with the first concepts you learn in OOP. Avoiding code duplication and abstracting it to an external class possible to have cleaner code and save resources.

The third principle is Single Responsibility principle.

Also very much related to the OOP basics, have every object focus on one thing only instead of multiple. That way for any behavior modifications, it will be easier as well.

Last principle is Liskov Substitution Principle.

This doesn’t have a self-describing name but basically it is about using inheritance correctly. The main object’s functionality or methods should mostly work in the subclasses as well, otherwise it’s breaking the principle. If that is not possible, then such functionality should be delegated to another object.

Photo by Dorli Photography via Flickr

This is a wall of tools, tools help us be better and fast at certain tasks. They have some learning curve however.

 

Do you know what is analysis paralysis?

When being presented by a variety of options to choose from, some people tend to overthink what is the correct one and compare each extensively, often to the detriment of time waste and without considering that choosing a bad option would be lesser than not choosing at all due to this.

I have had this problem several times. Often you don’t know what to choose and are afraid of being wrong.

When a problem is so big, the best way to tackle it is to break it down to smaller pieces and then work on those one by one instead of everything simultaneously.

Where do we start?

Book defines architecting as:

Architecture is your design structure, and highlights the most important parts of your app, and the relationships between those parts.

What is most important functionality of the system? The core, the essence? That thing that makes the gears spin.

On a small note, this example I actually liked, instead of being silly dog doors, it’s a rather familiar and common item. Board games. What makes a board game, a board game? I would say the definition of the rules and the specifics to declare a winner or loser. Anything besides that is extra stuff.

Next concept on our list is Risk. What is Risk? Not the board game of course.

These Are Not the Risks You Are Looking For photo by Ged Carroll via Flickr

Risk is the possibility of something going wrong with our system. We should strive to minimize the most possible risk. Reducing risk can be achieves by working only on features that serve our main objective.
It should be without mention, that a great deal of risk is reduced with good project planning before beginning to code. Good design will always reduce risk.

Another excellent point mentioned in the book, is that customers pay for great software, not great code. The way I understand it is that great code is code that could have been well written, clear, following languages’ conventions and works. Great software on the other hand, is well planned, well executed, meets the customer needs and is well designed. It involves more on the management side than purely the technical one.

 

Why is that funny? I don’t know for sure. Maybe because it’s extremely uncommon in Spanish speaking countries like Mexico. Now that I think of it, all human names should have been funny at some point.

You know what else is funny? Riding a rollercoaster. BIG rollercoasters. Tons of metal pieces put together in a way to maximize the experience.

This resembles software development, in a way. You built layer by layer, at the end is one big structure. As Ken has mostly said in class, it’s very unlikely we will see a project that is within a real architect’s size or scope while studying undergrad. Mostly due to the complexity of the projects being done.

Being a real architect is less about developing specific pieces of software and more about how all of them will work with one another and what technologies are the best tools for the job, ie the big picture.

Architects you could say work more closely with management, since the project vision needs to be very defined to ultimately help the customer’s needs.

For this purpose, there are tools to make it easier. Ones we have mentioned beforehand are use cases and UML diagrams. The architect uses them as they are a high-level view of what the system should do and doesn’t go into specifics.

A popular way of building big systems is to use the MVC pattern. Stands for Model-View-Controller.

Basically defines 3 parts of a system, how the data is stored, how it is accessed and how it is modified.

Architects are the orchestra’s conductors and the devs are the musicians.

Please enjoy one of my favorite pieces of classical music, courtesy of the BBC.

As always, you can find my other post about the topic here:

https://davidtc2004.wordpress.com/2018/11/22/building-legos/

So far I have written about the book chapters but focusing specifically on the actual topic at hand, the examples and silly storylines are not fun to read once, let alone a second time.

So now, for chapter 5, it’s the topic of change.

What is change? I would say when anything that is is no longer that but something else. Changes can be minor or major. In our context, changing software is a daily occurrence. As the book says, no software ever stays the same. No small apps like Paint (which Microsoft wants to kill for Paint 3D) to huge software projects like the Linux kernel or Windows itself. Hundreds of thousands, if not millions lines of code are changes hopefully to make it better, although that is not always the case. From bug fixes, to refactoring to feature requests, software is never the same.

This is Google. World’s biggest Internet search engine and services whose codebase is estimated at billions.

This goes in hand with good software development practices that make making those changes easier or faster. You can read more about that here:

https://tc2004david.home.blog/2019/01/22/new-year-new-opportunities/

Back to the book, the second part of the chapter now goes into OOP principles like cohesion and coupling.

Cohesion is that a object/class focuses on doing a single job. Removing everything that does not belong to it’s core functionality or can be outsourced. Coupling is how close or far objects are from each other in terms of functionality.

 

 

 

Coming into Chapter 4, guess what, the system needs to change again!

The main topic this will be analysis, more specifically real world analysis. This means changing or adapting our software to work in a real life context.

It’s a meme that when a developer says “but it works on my machine” it means that it was not planned correctly. There are a lot of variables that come in hand when running the software in production or “real life”. Things we don’t account sometimes like frameworks, missing libraries, system resources or even outside of the software code, like how it is actually used by an end user in a way we didn’t account for.

When that happens, we need to update our use cases and in turn, our requirements. This is similar to what I posted about in my past blog post however, now the system needs to be more specific.

To accomplish this and keep the software within the good practices of software development, we need to use what is called Textual Analysis. This reads really deep into the use cases and how are they described to look out exactly what classes need to be created and what functionality each needs to have.

This goes back to another Object Oriented Programming concept which is encapsulation. Having a correctly defined use case as well as class diagrams allows us to avoid having duplicate code and avoiding having extra functionality in a class that does not require it but instead needs to be it’s own.

It is basically defining who does what and how it does it. Does it send a message to another object? Should it be doing it itself? How is the data stored? How much data is handled?

Ultimately, it comes down to working with the customer as well as the end users to analyze how the system is being used to verify it meets the intended functionality and fits within the previously defined requirements, and if not, make adjustments.

We can use several tools like UML Class diagrams, which allow a high level overview of the system components that make it easily readable by less technical people. The main benefit of it is that is shows the overview of the objects and it’s functionality but doesn’t go into specific technical implementation of such.

I bet you didn’t plan for feline obstacles

Photo by Cassandra Leigh Gotto via Flickr

As you know, my past blog post on the same topic where I discuss the uninspiring book examples, can be found here:

Taking things out of context

Godspeed.

On Chapter 3 of the book, there’s a twist from what we have been working on from the previous chapters.

We have defined our use cases and gathered requirements but now the customer is asking us for something else. It can be a different way of accomplishing the same task, removing functionality, adding functionality or simply unexpected scenarios.

As it mentions, no matter the programming language, the task at hand nor the company you work for, the one thing that will always exist in software development is change. Software changes, the requirements change, tools change, methodologies change, EVERYTHING!

It is our job as Software Engineers to accept that and work towards solutions that help our customers.

Photo by lt col jjf usar ret via Flickr

Some interesting points not mentioned earlier when we were discussing use cases were alternate paths as well as optional paths. What are those you might ask. An alternate path fits within a given use case that is an alternative way of doing a process but very important, that it works towards the same goal as the main path. The optional path is a substep within a use case that may or may not be used in a certain scenario.

Now that we are mentioning that, what is a scenario? You can say it’s the full use case, starting from the first step until the last one. A scenario can have, like a use case, alternate and optional paths.

If you want to read a interesting quote from the Bethesda videogame series and how it compares to Software Development, you can refer to my blog post here:

War never changes, software does

Where I also refer to the laziness within the example scenario given in the book about adding a bark detector to a dog door.

Godspeed.

“Everybody loves a satisfied customer”. Who doesn’t?

Isn’t it this capitalist work everything an exchange? A business owner obtains money and the customer obtains what they want. However, this is not always straightforward.

In the world of software development, if one thing is certain is that nothing is certain. Things are ALWAYS changing. There is always a customer, either your employeer paying for your work, or a end-customer paying you for software. We can face change in two ways, accepting the change and give customers what they want or give them what they need. Very rarely these two are the same. It is the job of software engineers (and some project managers) to define exactly what will be done. This is called Gathering Requirements. There will be a more in-depth look into change for Chapter 3.

Image via Flickr @stavos

I don’t really feel like talking about strange and oddly specific examples of smart dog doors so I’m going to stay more in topic here. In case you wanna read my sarcastic commentary about it, please refer to my earlier post about the same thing here:

https://davidtc2004.wordpress.com/2018/11/21/the-customer-is-not-always-right/

So now, what is a requirement you may ask, the book tells us the following:

“A requirement is a singular need detailing what a particular product or service should be or do. It is most commonly used in a formal sense in systems engineer or software engineering”

Or the tl;dr version is, what your app needs to do correctly (We are in 2019, everything is an app nowadays).

So how do we get requirements, or a list of requirements?

First, we need to talk to the customer to see what they want. Depending on our social and communication skills (sorry introverts), we may also understand what they need right away. Another important piece of info here is that part one is what the software needs to do, the second part is how to do it. Talking with the customer and how listening on how they would use the software we can define a use case. This is a specific scenario based on a specific user action that has a specific outcome. If a specific step within a use case doesn’t work or is not available, we can also define the alternate paths which will help us reach the same goal.

We can have lots of use cases if there’s a complex system to develop, however, there’s a point where it becomes a waste of time. So they should not cover all the edge cases, just the common ones so we can begin creating it as soon as possible.

Or Life cycles, if you will.

https://www.flickr.com/photos/awesomefallen/9845281094/in/photolist-fZZD4L-DN3y7Q-ef7o2u-YAvR41-cXKudj-24qLVgQ-as2i5J-nacuHZ-s6xZZW-28U99RU-dskK78-8gGApy-aiL7Cw-Qoo9q4-bVi1eK-XQmHAd-oz2Xsv-24kScQG-qSrQat-bqQBp3-hcRVmv-dnhA8T-28DjN7w-aKtmx8-5isJDN-fgFrLg-TnuW2P-22g4rD9-VmC2b1-EGA136-69syce-dFVzFn-bBExsq-JXGXU7-4zxnhg-T1FsUs-oxc54t-dNNuqC-VZUTS1-8DwAYc-BNR9Va-a6u2U3-aydX6b-5ak9dv-7GV3Ae-nXBUui-dbaATe-diceBo-dpe33u-ngJvmw

Image via Flickr, @awesomefallen

All software projects have a lifecycle, like most things. It begins with the creation. Unlike real life, software projects must have a meaning. Most of the time that is to either solve a problem or accomplish a task.

It has several steps:

1- Purpose or Problem: Plan or define what needs to be accomplished.

2- Analysis: Can it be done? How?

3-Planning: defining the top priorities as well as the time it would take.

4- Requirement Analysis: A fancy way of saying what behaviors will the app have to accomplish its objective.

5-Development: Begin doing the code and looking that it runs!

6- Testing: Does it run well on standard workflows only? Or does it also take into account non-standard workflows as well?

7- Integration: Now it runs and does what it is supposed to.

8- Maintenance: Need to take into account future changes, as well as any extra steps that need to be done after it is up and running to ensure it stays that way.

Sources:

Systems development life cycle
https://en.wikipedia.org/wiki/Systems_development_life_cycle

What is SDLC? Understand the Software Development Life Cycle
https://stackify.com/what-is-sdlc/

Well, guess who is taking the same class again from last semester with Ken? Yup, that’s me. Queue your sitcom comedy intro.

So, what are we gonna talk about now? Well it’s something like the same…. without being the same. This time I will definitely complete all the masteries. Hope you’re reading this Ken!

Regarding the chapter books, well there’s not much new. The book is the same old one as last time. The chapters didn’t change so I’m unsure if I should change my blog posts about them. Maybe since I will not be on a last day rush, I could expand on some ideas more.

Enough with the intro nonsense, lets begin.

So….. chapter one…. chapter one…. chapter one….

Great software. What is great software? Let’s see, WITHOUT reading my last blog post on it, if I recall correctly, great software means writing code that is easy to maintain, easy to understand and most importantly, that works and suits the users needs.

It matches very closely however. I wrote that great software has to be:

• Easy to read
• Easy to maintain
• Do what it’s supposed to do (THE most important thing)
• Reusable
• Optimized (even though, I don’t always write optimized code myself… yet)
• Helps the user.
• Usable

Now, comparing to the book, I only missed the extend characteristic. The book mentions “well designed” and “well coded” which we can take my “usable” and “optimized” characteristics for.

So the general idea is still there. 

Should I write again about all the incredibly convient and specific and not-really-going-to-happen-in-real-life examples the book uses? Maybe, maybe not. I guess I will see on the next book chapter.

If you read it all the way until here through my initial ramblings, congrats! you have a good attention span. Better than me sometimes. See ya later.