Programming VS Developing

I will put two codes. The problem is from the web page:

I was curious about how people code there. I could not be more scared after seeing things like this one:

or this one;

Well, the previous two are programmers, but they definitely are not developers. Developers at least try to do something like this;

import java.util.Scanner;

public class Solution {

	public static void main(String[] args) {
		Scanner in = new Scanner(;
                int freewayLenght = in.nextInt();
                int testCases = in.nextInt();
                Lane lane = new Lane(freewayLenght);
		for (int segment = 0; segment < freewayLenght; segment++) {
			lane.setWidth(segment, in.nextInt());
		for (int i = 0; i < testCases; i++) {
			int entry = in.nextInt();
			int exit = in.nextInt();
			System.out.println(lane.minimumLane(entry, exit));


class Lane{
	int laneWidth[];
	Lane(int laneLenght){
		laneWidth = new int[laneLenght];
	void setWidth(int segment, int width){
		laneWidth[segment] = width;
	int minimumLane (int entry, int exit){
		int minimum = 3;
		for(int i = entry; i <= exit && minimum > 1; i++){
			if(laneWidth[i] < minimum){
				minimum = laneWidth[i];
		return minimum;

Do someone see the difference? Can you read the first two? Do you know what they do just by looking at them? What are the entities of the world you are dealing with? Potatoes? In the difference is the answer of what is a programmer and what is a developer.   Read the problem and constrains here:

Engineering is in the small details

What is really engineering? In Wikipedia:

Engineering (from Latin ingenium, meaning “cleverness” and ingeniare, meaning “to contrive, devise”) is the application of scientificeconomic, social, and practical knowledge in order to inventdesign, build, maintain, and improve structures, machines, devices, systems, materials and processes.

We had this issue in my lab.

There is an AC machine that it is placed in the middle of the room. If we divide the room in three columns c, being a mathematician, we would say we have from c1 to c3. Well, the AC is in c2. The whole column c2 feels cold, since the AC points directly to them. I am in c1, so I feel hot and there is no way I can work feeling hot.

Event 1. Can I turn on the AC? c2 said yes.

Event 2. c2 feels cold.

Event 3. The degrees are 26, so it should be fine. The problem comes from the direction. The wind points directly to c2. I check how to change the direction of the wind since there is no one sitting below the AC.

Event 4. The AC does not work properly, so we can’t make it to point down.

Event 5. Since we are not AC engineers, we cannot guess the problem.

Event 6. People wants to turn it off. I said, wait. I will give it a though.

Event 7. I find a small cut-off piece from a poster we have in the lab. I came with the idea of using the paper to direct the wind.

Event 8. How can we stick it here? We cannot stitch.

Event 9. I found some magnets. Let’s use them.

The final result looks like this:


Notice that with the paper in the middle we block the air only in that direction.

Everyone is happy now. No more than 5 minutes. Low-cost, using a cut-off piece of a poster.

Well, I think this is engineering (And that I am kind of stubborn, yes). The key for this, keep trying.



Learning Object-Oriented paradigm course

Long time ago it came to me a C code of an application called CommandLine that it had to be translated to Java. The purpose of this exercise was to see that in Java you can code without using Object-Oriented programming, so people can realize that they should understand what is Object-Oriented programming and not calling everything Object-Oriented just because they use classes. I lost the requirements sheet, so I cannot tell exactly what was in there, though the code is simple in requirements (and messy in the original implementation).

This is the code that was translated from C to Java without using OO. I called it Under-engineering:!EAA0AA4K!s01950d-vpXc10WEehVc6ior-AFwJ3sXBzUQT-Ds3pU

I called it under engineering because later on we built up the opposite code, the Over-engineered version. Many of you will find easy to realize about the bad things in both codes. This does not happen with first learners. They are not used to structural or functional programming and they start learning object-oriented from the beginning. It is more difficult then to realize what is what. For that reason this course was created.

This is the code of the over-engineered application:!lE5W2KBC!F8YlYM6X1_WquymNesBE2US5jRjP4qSjJIi7yHKHVig

Recently, I collaborated in a class to help people understand when they over-engineered or under-engineered. I created a code from the two previous old versions to try to find a good spot where design and simplicity are present. Here is the code:!VMwniRzI!vRxFe1dhgkAHD7Uy8k7cBXfBnRNiEOgC6FeO-mx6Jfw

Since I lost the requirement sheet and I made it in a couple of hours it may not be perfect, but it helps people to realize when they think too much in future or too less. Feel free to use or modify these codes. They are for educational purposes so if you find better approaches or you have comments on it, let me know!

I created a Word in which I explain my process of thinking so other people can see why I do or think how I think. Here is the word file:!4N4hTKpa!xUkOZb7-d5kCwb0q-5Iv6GA7BXS0F33SM9rnEWUPm0A

Of course, I am no God in here, but definitely with these codes we could encourage people to think and discuss if it is wrong or not and how to improve it.

Also, I recommended the Chapter of Refactoring in the book

The term #Agile

Many people keep using agile as a noun (me myself, I do sometimes) to referring to Scrum/XP. Probably because of the boom of agile methodologies, people usually accompany the agile principles and manifesto with a real thing to implement, such as Scrum or XP. Also, this is probably due to the fact that Scrum and XP are the specific agile methodologies most used around the world and better known. Sometimes I forget FDD is considered, for example, agile. I am pretty sure in my brain FDD and ScrumXP do NOT fall in the same category, so I do not like the idea of these being in the same bag.

The use of the term can lead to confusion if you use it with people who treat it differently. Nevertheless, most of the people is talking about “agile ScrumXP” so in general people is understanding each other somehow.

On the other hand, there is the term “methodology”. In an unfortunate event someone called it methodology. People started to realize that Agile is not a methodology but a mind-set. Method is something way far from the idea of Agile.

I personally would distinguish for the sake of clarity in this way:

– Use Agile/agile as a name (it is easy), preferable the first one, though I know most of the people will not capitalize the first letter. To distinguish both most common ways of using agile I would use Agile Origin(AO) for the principles and manifesto and Specific Agile(SA) to talk about ScrumXP or similar tool. If someone ask you what kind of Specific, you should answer Scrum, FDD or whatever you are thinking in, but by default, if you do not mention it before, it should be Scrum and XP.

– I would also talk about Extended Agile(ExA) as the combination of Scrum-XP-Lean-Kanban. The reason is that usually we include Lean and Kanban with ScrumXP since they actually seem to combine naturally.

Whatever you use, people should understand each other. At the end the main thing is communicating properly.

Why SAFe still does not convince me

First of all, this is just a bunch of doubts and feelings I got reading about SAFe framework in their webpage. I am no expert in anything here but for me these questions and problems I propose here needs to be addressed.

Nine methods to split epics are just epic

Isn’t too much all those methods? One of them is use case scenarios, for example. What is new with this and why coming back to create use case scenarios is good for splitting epics. In my understanding of epics, mostly with a bunch of people giving it a though and agreeing with one option it would be just fine for many cases. Feel like a YAGNI.

Poor connection of everything they use in their framework

Well, a framework should act as a framework and if you create one you should explain properly the connection between the parts and how they interact. With that big picture image you get a lot of partial concepts mostly fine when you click on them but difficult to paint into your mind a real/big scenario, with all of the parts working together in a successful way.

Too big with too many elements

I cannot imagine a normal organization moving from their current status to all of that. Seems overwhelming. And if they do not do that, they are not using SAFe I guess, so how can we really know if SAFe works well as a whole for most of the companies? I saw the combined picture with waterfall + agile projects running at the same time, with the portfolio and all. It just seems not practical to me. Though I am no one here to say anything since my experience is limited.

They encourage the old(?) project management role, not Scrum Master

And they affirm somehow: In large projects, you have to use project managers in the traditional way (and they know about it). Also, project manager figure is kind of odd(close to a god), becoming business analyst, system engineer, product owner and seems to point to whatever means to be a boss for tech guys. They also support the International Business Analysts definition of Project managers, which has the requirement elicitation and all the packages inside.


Same level of prescription as RUP, but prescribing agile, lean, scrum, XP, Kanban, DevOps, and an endless list of smaller tools. It seems to me prescribing the other pedestrian’s side of the road too.

The only measure is the output, but just in case, take these 8 metrics

Those 8 metrics are interesting though many “waterfall metrics” were interesting too, and look where they ended at the end in many companies. How much effort does all of this take? What is the Return of Investment in these particular metrics? Can we see it in the Cost of Delay or something? When some metrics, when not?

What is new with SAFe?

I asked to myself this question. Well, I did not find anything. Well, to be fair, the connection of everything with a picture, which is good and a rather simple explanation of every element is the new thing in my opinion.

That lightweight business case and many others seem to have the same issues as the Use Cases and documentation

Check the lightweight business case image. And then the epic statement template format. And then the examples .xls of the metrics. And then the… Lightweight with respect to what? Cannot we make lightweight more lightweight? I know Rally or other applications will “help” with it but it seems too much to me as a whole. The team self-assessments are just epic.

The architectural epics system?

The graphic and explanation of Funnel > Backlog > Analysis > Implementation recalls me too much to the Elicitation > Analysis > Design > Implement > Test. This is at higher level though. I still need a better explanation for this though.

You cannot copy from their webpage

This is seriously, seriously annoying. I do not understand why they do that. They only thing they get is to make us difficult to cite them and people gets bothered. I cannot criticize properly a part of the text because I am not going to write down the whole text. And then people can doubt my critics if I do not put the text. Really annoying, again. If you copy the text as an image, I bet they will sue you for citing without permission.

I agree somehow with Ken Schawber in this:

I feel after reading a lot of SAFe like Sun Tzu said in the Art of War. “Leave the politics to the politicians and the war to the generals. When one of these roles try to get into the others’ one, nothing but failure is expected to be the output”. (From the spanish version, rephrased by me)


How to assess your organization culture in one question

With one question you get to know how is your organization


sk8 2

I was doing an Enterprise 2.0 Masterclass to a group of technical national directors at INSEP (French national institute of sports) and one of the attendee asked me this question : “How can I quickly assess my organization culture ?”

It has just occurred to me that this can be carried out very easily, asking just one question, so I asked them :

View original post 277 more words


Well, I don’t know why I did this work even. It was long time ago, when I was starting my PhD. I see it now as a very naive work and pointless(?). Anyway, I am going to share my effort to unify XP into Scrum, so we don’t need to think much in (I guess) what are the steps we gotta do.

I guess this pointless work was a good lesson though. I got to understand better the main “agile frameworks”.

I leave it here just in case people can find some wisdom (I can’t anymore, or there is no hahaha)

Link:  XP@Scrum

The doubts I had solved: XP@Scrum clarifications

How to write a paper

If you are researcher, you definitely have arrived to the point you want to suicide just because you have to write your research into a more formalized way. I felt the same with coding. I usually spent 2 hours coding and 10 hours testing in many different ways. Well, that is life, and it is how it should be done. Accepted.

Recently I realized I made way so many presentations that I could present a simple box like an awesome invention hahaha. Jokes out, I will publish here some of my presentations so maybe it can help you say you my work (I know how life works, it is OK).

Today I will publish the one I made when I was learning how to write a paper. MY WEAKNESS, DEFINITELY.

In this presentation I summarized a great article:

Whitesides, G. M. (2004). Whitesides’ Group: Writing a Paper. Advanced Materials, 16(15), 1375–1377. doi:10.1002/adma.200400767

and I think I added some of my experiences (This was long time ago so I don’t remember well).

Here the link: how to write a paper

Impact Mapping, will it rule over?

What is impact mapping? For me, the first idea that came to my mind while reading how to make an impact map ( is those days I was studying Goal, Question, Metric ( Everything seemed very beautiful with GQM, though at the end I have never seen it in the industry. I have studied so many things in many years to just realize they were “obsolete” the year after. What the theory says is good and what is really used differs so much that I understood very well the terms de facto and de iure.

Nevertheless, I have the feeling that Impact Mapping can have a good impact in the industry (hehe well, what a name! I promise I did not joke like that intentionally). From my short experience, good things won’t enter the industry if there are not one of these two set of factors happening (or both):

* The engineer factors: Simplicity, easy to use, useful, satisfaction. So we us it. (So if we want to convince an engineer we do not talk about profit, we talk about simplicity, elegance, etc.)

* The business factors: Savings. Profit. Marketing. Other companies use X by trend, so as we do. (So if we want to convince a bussines man, we talk about savings, profit, marketing, etc.)

I think Impact Mapping is simple and strikes a very important point that is, how we can have a traditional big company with old values and old management and old mentality having an IT department with new ideas, new mentality, new approaches. We have to be or old styled companies or new styled companies, but being in the middle usually is not a good option.

But let’s see if it goes berserk in the industry :D.

Respect, delegation, trust, role rotation

I got to know recently the term Anzeneering by Joshua Kerievsky. It is better you read his blog to get the idea. Mainly the thing is that different roles suffer from different things. We should identify these pains and protect people from them.

Also, recently I was reading about DevOps and I think it is related in some way. Different roles have different needs and perspectives. I think protect people seems to be finding respect between roles and trust them in their professionality.

“In a nutshell, the conflict between development and operations is as follows:

  • Need for change: Development produces changes (e.g., new features, bug fixes, and work based on change requests). They want their changes rolled out to production.
  • Fear of change: Once the software is delivered, the operations department wants to avoid making changes to the software to ensure stable conditions for the production systems.”

From the book:

DevOps for Developers
By: Michael Hüttermann
Publisher: Apress
Pub. Date: September 12, 2012
Print ISBN-13: 978-1-4302-4569-8
Print ISBN-10: 1-4302-4569-7
Pages in Print Edition: 194

I would say, protect the different roles through understanding and respect. We all follow the same goal. Don’t push teams. Delegation should come with trust. Spread responsabilities. Rotate team roles so they become empathic.