Software Construction

--Originally published at Enro Blog

The construction process might include some aspects of planning, designing, and checking your work, but mostly “construction” refers to the hands-on part of creating something.

in the short time software development has existed researchers have identified numerous distinct activities that go into software development. They include:

■ Problem definition
■ Requirements development
■ Construction planning
■ Software architecture, or high-level design
■ Detailed design
■ Coding and debugging
■ Unit testing
■ Integration testing
■ Integration
■ System testing
■ Corrective maintenance

And thats a lot of red tape.

Putting construction in its context with other activities helps keep the focus on the right tasks during construction and appropriately emphasizes important nonconstruction activities.

Anotación 2020-02-19 232538


Construction is mostly coding and debugging but also involves detailed design, construction planning, unit testing, integration, integration testing, and other activities.

Why Is Software Construction Important?

  • Construction is a large part of software development. Depending on the size of the project, construction typically takes 30 to 80 percent of the total time spent on a
  • Construction is the central activity in software development. Requirements and
    architecture are done before construction so that you can do construction  effectively.
    System testing (in the strict sense of independent testing) is done after construction
    to verify that construction has been done correctly
  • Construction’s product, the source code, is often the only accurate description of the software. Requirements specifications and design documents can go out of date, but
    the source code is always up to date. Consequently, it’s imperative that the source
    code be of the highest possible quality
  • Construction is the only activity that’s guaranteed to be done. The ideal software project goes through careful requirements development and architectural design before construction begins. The ideal project undergoes comprehensive, statistically
    controlled system testing after construction. Imperfect, real-world projects, however,o ften Continue reading "Software Construction"

The Seams model

--Originally published at Enro Blog

A program can seem like a large sheet of text. Changing a little text can cause the meaning of the whole document to change, so people make those changes carefully to avoid mistakes.

Superficially, that is all true, but what about modularity? We are often told it is better to write programs that are made of small reusable pieces, but how often are small pieces reused independently? Not very often. Reuse is tough. Even when pieces of software look independent, they often depend upon each other in subtle ways.

A seam is a place where you can alter behavior in your program without editing in
that place.



Michael, C. (2008). Feathers. Working Effectively with Legacy Code.

Sensing and separation

--Originally published at Enro Blog

Sensing and separation

Generally, when we want to get tests in place, there are two reasons to break dependencies: sensing and separation.

1. Sensing—We break dependencies to sense when we can’t access values our code computes.

2. Separation—We break dependencies to separate when we can’t even get a piece of code into a test harness to run.

There are many techniques for Separation but one dominant technique for sensing.


One of the big problems that we confront in legacy code work is dependency. If we want to execute a piece of code by itself and see what it does, often we have to break dependencies on other code. But it’s hardly ever that simple. Often that other code is the only place we can easily sense the effects of our actions. If we can put some other code in its place and test through it, we can write our tests. In object orientation, these other pieces of code are often called fake objects.



Michael, C. (2008). Feathers. Working Effectively with Legacy Code.

different Rightmost Bit

--Originally published at Enro Blog

You’re given two integers, n and m. Find position of the rightmost bit in which they differ in their binary representations (it is guaranteed that such a bit exists), counting from right to left.

Return the value of 2position_of_the_found_bit (0-based).


  • For n = 11 and m = 13, the output should be
    differentRightmostBit(n, m) = 2.1110 = 101121310 = 11012, the rightmost bit in which they differ is the bit at position 1 (0-based) from the right in the binary representations.
    So the answer is 21 = 2.
  • For n = 7 and m = 23, the output should be
    differentRightmostBit(n, m) = 16.710 = 11122310 = 101112, i.e.


    So the answer is 24 = 16.

int differentRightmostBit(int n, int m) {

  return (~(n^m)+1)&(n^m);

this is a similar problem to the last bitwise problem I posted this week.

  • Turning all the different bits to 1 is straightforward with xor:
    n XOR m
  • Turning all the bits to 0 is also straightforward with AND and NOT:
    (n XOR m) AND (NOT(x XOR m))

if you n & ~n you get 0 but if you  n & ~n+1 you get the first value that was 1.

Second rightmost zero

--Originally published at Enro Blog

This is a problem excersice from codesignal platform.


Presented with the integer n, find the 0-based position of the second rightmost zero bit in its binary representation (it is guaranteed that such a bit exists), counting from right to left.

Return the value of 2position_of_the_found_bit.


For n = 37, the output should be
secondRightmostZeroBit(n) = 8.

3710 = 1001012. The second rightmost zero bit is at position 3 (0-based) from the right in the binary representation of n.
Thus, the answer is 23 = 8.


You have to get rid of the rightmost 0
To fill in the rightmost 0 with 1 using x | (x + 1)
    10111100  (x)
|   10111101  (x + 1)
Isolate the new rightmost 0
To isolate it use ~x & (x + 1)
// now x is the value after step 1

    10111101  (x)
    01000010  (~x)
&   10111110  (x + 1)
 in short 
  return ~(n|(n+1)) & ((n|(n+1))+1) ;

Working with feedback

--Originally published at Enro Blog

Changes in a system can be made in two primary ways.

Edit and Pray is pretty much the industry standard. When you use Edit and Pray, you carefully plan the changes you are going to make, you make sure that you understand the code you are going to modify, and then you start to make the changes. When you’re done, you run the system to see if the change was enabled, and then you poke around further to make sure that you didn’t break anything. The poking around is essential. When you make your changes, you are hoping and praying that you’ll get them right, and you take extra time when you are done to make sure that you did.

Cover and Modify is a different way of making changes. The idea behind it is that it is possible to work with a safety net when we change software. The safety net we use isn’t something that we put underneath our tables to catch us if we fall out of our chairs. Instead, it’s kind of like a cloak that we put over code we are working on to make sure that bad changes don’t leak out and infect the rest of our software. Covering software means covering it with tests.

Cover and modify means coding with tests, when we have a good set of test around a piece of code we can make changes and find out very quickly whether the effects were good or bad. Testing this way is “testing to attempt to show correctness“.

“Testing to detect change” is called regression testing. We periodically run tests that check for known good behavior to find out whether our software still works the way it did in the past.

Unit testing is one of the most important components Continue reading "Working with feedback"

Changing Software

--Originally published at Enro Blog

Changing code is a complicated task, there are ways we can come up to make the code extremely difficult to read for other developers on the other hand there is also ways to make it easier for future developers to understand.

But why do we change software ?

four main reasons.

  1. adding features,
  2. fixing a bug
  3. improving the design
  4. optimizing resources

Adding features and fixing a bug are only different in which point of view you are looking at it, for the customer something trivial may be a bug because he dosnt want it that way but for developers it may mean a new feature, never the less they have the same basic mechanic, we change the behavior in our application.

Behavior is the most important thing about software. It is what users depend on. Users like it when we add behavior (provided it is what they really wanted), but if we change or remove behavior they depend on (introduce bugs), they stop trusting us.

The act of improving design without changing its behavior is called refactoring. The idea behind refactoring is that we can make software more maintainable without changing behavior if we write tests to make sure that existing behavior doesn’t change and take small steps to verify that all along the process.

Optimization is the same as improving the design only with a different goal, we want to make the resource of a program low being this time or memory.

In general, three different things can change when we do work in a system:

  1. structure,
  2. functionality,
  3. and resource usage.

Preserving existing behavior is one of the largest challenges in software development. Even when we are changing primary features, we often have very large areas of behavior that we have to preserve.

Risky change

To make good code Continue reading "Changing Software"

Introduction to legacy code

--Originally published at Enro Blog

The code must be flexible enough to accommodate to change, change is a constant matter in software development and is such an important task that many if not most of the developers that join the software forces at the moment are tasked primarily with the task of maintain software and not many of them will ever get to write code or

develop new features or applications.

But what is legacy code?

In the industry, legacy code is often used as a slang term for difficult-to-change code that we don’t understand. But over years of working with teams, helping them get past serious code problems, I’ve arrived at a different definition.

To me, legacy code is simply code without tests. I’ve gotten some grief for this definition. What do tests have to do with whether code is bad?

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well- encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

Michael, C. (2008). Feathers. Working Effectively with Legacy Code.


--Originally published at

Finally after four long months the end of the semester arrived, perfect time to become nostalgic and do a retrospective analysis.

First of all we had to understand a very important concept of the course: what is a smart city, “kp2” with the course name? A smart city is a designation given to a city that incorporates information and communication technologies (ICT) to enhance the quality and performance of urban services such as energy, transportation and utilities in order to reduce resource consumption, wastage and overall costs. The overarching aim of a smart city is to enhance the quality of living for its citizens through smart technology.

They always put people first. In the approach to the Smart Cities Mission, the objective is to promote cities that provide core infrastructure and give a decent quality of life to its citizens, a clean and sustainable environment and application of ‘Smart‘ Solutions.


Once understanding this we could select a project (and a team hehehe) to perform throughout the course. And that’s how the super powerful girls were born: Constanza, Mark, Gabo y David whom throughout the semester developed a bike user application as an extension of a bike rebalancing predictive system for the Guadalajara Bike Sharing System (BSS) called “MIBICI”.

It was during this development that we realized how smart city projects are related with ethics. Our case was not nothing special, we simply had to find a way to explicitly ask our users to access their location and allow us to save a history of their travels. Recalling that according to the GDPR (General Data Protection Regulation), the consent must be informed, explicit and unambiguous.

Here was another important concept: transparency. Within the scope of ethical values, transparency is known as the ability of a human being for others to Continue reading "Diuan"

Course Evaluation

--Originally published at

Screen Shot 2019-05-08 at 2.57.22 PM

I think that usually in our classes nobody asks us to read, investigate and reflect about something, due to the degree we are studying the majority of the homework are about coding, doing diagrams or another kind of more systematic tasks. Doing this blogs help me to do not completely forget that communication/reflection skill.
I like better when there were defined topics for weeks, because even having a topic is an open theme, but not enough than you do not have an idea of what to talk about, specially the one about Ana Rodrigues.
The class with the speakers was nice, interesting, I think it would have been great if we had more like that.
Regarding for topics and even the project I think that for me this was a class that make me reflect a lot about ethics, law, security and privacy related with technology. Relationship with technological solutions with people.