Archive | Uncategorized RSS for this section

Programming VS Developing

I will put two codes. The problem is from the web page: https://www.hackerrank.com/challenges/service-lane

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

https://www.hackerrank.com/rest/contests/101nov13/challenges/service-lane/hackers/spartanz/download_solution

or this one;

https://www.hackerrank.com/rest/contests/101nov13/challenges/service-lane/hackers/pankajnirwan103/download_solution

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(System.in);
                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));
		}
		in.close();
	}

}


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: https://www.hackerrank.com/challenges/service-lane

Advertisements

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:

Workaraound

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.

 

 

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.

Prescriptive

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: http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/

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

#hypertextual

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

XP@Scrum

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

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 (http://impactmapping.org/drawing.php) is those days I was studying Goal, Question, Metric (http://en.wikipedia.org/wiki/GQM). 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.

http://www.industriallogic.com/blog/anzeneering/

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.

Work to do

Recently, I talked to a friend who is an analyst in a renamed company. I was curious about the way the company works and the view my friend has about the company, the situation, etc. Two things especially captured my attention:

– My friend said that they have a manager figure, planning and so on, but apparently useless for my friend, doing nothing, or nothing significative. A few times he came and ask, “everything alright?”.

– They had to fulfill some sheets to control the productivity of the workers. If they don’t achieve some goals or minimum they are fired. Apparently that thing happened quite often.

I didn’t have much time to talk since we were with other friends that didn’t like much our topics. Nevertheless, with these two bullets you can guess there is still a lot of work to do in the way companies still work.

The theory-practice gap. El Deterioro

I am using this blog for writing my thoughts since a PhD is most of the time reading, summarizing, analyzing, etc. but it is really hard to work on what you really want to work, the things why you started your PhD. To check one idea, it takes you years within a PhD. The reason is the complexity of the “science” process (that already Rene Descartes wrote down very well). But I am not a scientist. I am an engineer. We don’t seek for the perfect answer, we seek for the optimum answer. Scientist don’t pay “attention to money”*, just true or false. Ironically, software engineers are constrained by money, society or human nature in general, technicalities, etc. We work with the hands cuffed, in terms of the solution we have to provide.

It is hard to know when we are being too theoretic and when we are being too practical. With agile frameworks, it happens the same I guess. There out there dozens of agile methods but recently I am wondering why Scrum, being so old wasn’t beaten already by the newer ones? My answer is iPhone. Everyone is familiar with iPhone nowadays (also important to be successful). Why iPhone is such a success? The same why Scrum is a success. Usability, which means user satisfaction, simplicity, less user-error prone, etc. Made for the mass. I was discussing not long time ago with one of my colleagues. He was telling to me that Android can do much more things, like A,B,C, and it is really easy, just swiping three times and touching one corner while you are standing up with one leg (just kidding, it is just for you to get the idea of what happened, I love Android too). I just said to him, give that to your mother, teach her how to use it in two ways (the fast-weird and the stupid-long) and wait to see which way she will use. We both knew the answer.

With Agile frameworks, IT IS THE SAME. Scrum is an “optimum” success because the gap between theory and practice is almost zero in comparison with other frameworks. Everyone understands it. Moreover, Scrum puts over the table just a few things, which is basically the skeleton and an easy common language. I don’t need to know a damn thing of computers and their boring problems, that I can understand Scrum. So, I can sell it to the business layer. And we use the same terminology. Later on, for the technical things, whoever-business-guy could say: “deal with that engineers! that is already your job!”. And it is true. Scrum allows you to define a link between business and IT, that is all.

Other thing is the deterioration rate (El deterioro) that agile frameworks have. I have never seen anyone considering that some agile methodologies deteriorates more than other ones. People in software are talking about “ideal materials” but building’s architects can tell you that any material, no matter which one, deteriorates with the time. With methods I think it is the same. They deteriorate, and at different rates, due to the duality theory-practice, depending on many factors. And most of the time they never get to their súmmun. And the problem of some methods is not really the things you have to do. It is the way it goes if you try to do that.

Of course, the real world is not perfect, and you will face zombies sooner or later. Moreover, there are many problems with Scrum that need to be addressed, especially in a globally distributed project. I wish one day I could arrive to the point I can apply my ideas!

Note: Good marketing is also part of the key. But there are only a few companies that can survive with bad products and good marketing. Usually huge ones.

Note 2: I would like to check how square heads we are, software engineers. In a changing environment like the one we have, we gotta be flexible and we have to break with the old concept of engineer (and I was one of the lasts old engineers produced in my university… thankfully-sadly).

* I mean, they need money, but they don’t look for solutions to daily problems, they want to reach the “truth of the nature”. Though most of the scientist have to find nowadays practical uses to their researches, but that is other thing. Scientist nowadays are engineers in general, because in our days, invested money have to lead to benefits. But let’s stick to the traditional concept.

Assumptions? How can we introduce agile better?

I`ve been in this country for more than 10 months. I mean Japan. I have been working with japaneses in a daily basis and I realized the specific details of their culture. Keio or Todai or NTT or Hitachi or whatever, I found myself in a completely different culture of work. They are not like us and we are not like them (well, in my case I would say I am mediterranean guy since I realized while living here how close greek, italians or even turkish are to me in comparison with asians in general). Also, mediterranean people suffer some gap with anglo cultures. But it is not so big. I have read about it. Nevertheless, frameworks/methods or whatever are barely adapted to different cultures. I wonder if we are assuming some kind of things. I explain myself. I am andalusian, and I worked in a big company for more than one year. In this company, I realized how low is the trust that client and developers have back there in Andalusia. Before starting, everyone was assuming the things will go wrong and they will sue each other irremediably. So everyone signed many documents, created several other ones to feel protected. And of course they were right. It happened. Nevertheless, I don`t have this feeling in Japan. They do document, but they do it for other reasons. They like to have everything well established and controlled. Here we go then. There are agile methodologies. I have seen their awesome way of working (well, I have to forget my previous job where they used agile, or say so), but I still don`t know how they can penetrate in some societies in an easier way. The curve to introduce agile is more steady in some countries. Countries like US developed a very awesome way for being proactives. They do risk, they are ambitious to get money, and they do try. Not so easy near the mediterraneum.

I state: “To introduce agile we need to identify the needs and worries of the society, understand it and deal with these society needs with the framework proposed as a normal thing.”

Ok, I will put it some other way. I came to Japan with my bag of important things. I was in Japan, one of the safest places in the world but my bag was in front of me and if someone touch it, I rapidly reacted to see who is this person and what are their intentions. I am not special. We are taught like that, believe me. It is an inner stuff deep in your brain. Well, it took me months to leave my laptop alone a few minutes for going to the toilet. There are witnesses. In Japan, yes. You may not believe it, but that is how we survive back in my place. I remember my good asian friend who came to Spain to study and enjoy our culture and got robbed 3 times. 2 good cameras stolen! She told me what happened and I tough, obviously. What does this fact to do with agile? We are different, and we need to point different issues too. I believe there is a need here to introduce agile in a better way. Every andalusian person have been told hundred of million of times don`t trust people. So companies don`t neither. And it is survival.