UML in embedded (II)

Here we go again.
I had a short talk today on how to document design.
I make now a short resume of the ideas.
All designs needs to document (from a perspective of a single software component) two main areas:
- static description
- behavioral description

For the first one, you need to imagine what is the layout of your SW Component (functions, variable, global or not). Let's call this class diagram. Additional, you have to catch in one picture which are the provided interfaces and which are the required interfaces. Let's call this component diagram.
If you imagine an engine, until now you depicted the size, shape and how the engine can be mounted in the car.
Then, please think about the behaviour of the SW component.
Imagine some scenarios based on use cases. This can be depicted using sequence diagrams.
Go further and describe special algorithms via activity diagrams.    Don't use for each and every flow, it makes it only hard to read.
If you model your system based on states, don't forget state machine diagrams. Here, there is plenty of literature to read about modeling system based on state machine diagrams.

Here you go, takes this steps and try to document your work. Jack Ganssle makes a nice review on a new book, about documenting software. It goes in the idea of writing beside code. Al Stavely’s new book, “Writing in Software Development,”

I will come up next month with some ideas about how to mix Doxygen and tools like UMLet to make nice documented SW components.

Read More...

Mentoring journey

It seems that once your are nominated a mentor for others, you end your trip as mentee and start another one as mentor.
This is not true.
It is just the next step of mentee-mentor equation.
I have read recently a post on HBR.org about mentorship and started to look back in my life how this is going on.


Mentorship is not always official, not always coming from HR department. In my case, I realized that I had a great mentor only after more than one year. He was able to guide me through decisions without doing it by himself. The other thing is that he was not pushed to be a mentor, it has been somehow facilitated by some chemistry between the persons.
Look for a mentor relationship even this is not coming through an oficial channel. Look for more than one mentor that can help you to progress. You can return the favor by supporting their initiatives with candid feedback and a little bit of evangelism, when fitting to own beliefs.

The more the mentor is up on the performance scale, the more he can guide easily the mentee through the career journey. Some things come up easily, as there are so many things the mentee didn't experienced. It's like a basket full of toys of all sorts. Giving this to a child with very few toys, he can find in the first hours many things maybe new. He will be passionate about some of the things and spend more time with these ones. Others toys might not be of interest at all, as others are already boring.

The other thing is that mentee cannot discriminate which toys are inside the basket from the beginning. It's a matter of try-and-error for her and a matter of guidance from mentor to reach the meaningful items from the first tries.

The other thing in this equation is the purpose of the journey. If this is clearly defined and there is enough fuel for this (that is motivation), than the journey is smooth and direct. I've seen good guys rocketing to top with a clear picture of what they want. Others, with comparable potential and less vision about their destination, struggle in their way and sometimes even fail to reach it. How come this fuel is so important? Why is not enough to have a great mentor? Just because the mentor is the facilitator, she cannot overcome the lack of will. It's like the old joke with the old lady who is helped to pass the street. The mentor who push you to do the passing without your will is not doing a good deed. It is all about you working in a team and getting the right help.


In the end, one can be in both positions in the same time, as the organization is behaving like a pipeline. Look to get more while helping the others coming from behind to catch up. The team you will be part of has the chance to be great. You, alone, have the chance to shine like the sun in desert.

Read More...

Un sac plin de cadouri sau de oferte?

Baietelul meu este un fervent urmaritor al reclamelor.
Astazi, dupa o reclama Billa, intreaba foarte natural
Mos Craciun ne aduce un sac plin cu cadouri sau un sac plin cu oferte?

!!!

Read More...

Cultura organizationala (III)

Cat de repede se schimba o cultura organizationala?

Nu chiar repede. In circa doi pana la patru ani, in functie de cine e motorul acestei schimbari si cum este structurata organizatia. O organizatie plata, cu putine nivele si manageri charismatici este mai agila si poate asimila schimbari culturale mai rapid.

In cazul organizatiilor piramidale, aceste schimbari sunt mai lente sau de deloc, pentru ca ajung foarte greu la nivelele care trebuie sa le asimileze. Cand eram mic, jucam un joc foarte amuzant, numit "telefonul fara fir". Eram asezati in rand si trebuia sa soptim la urechea celui de langa noi un cuvant, de multe ori complicat. Toata distractia era sa aflam la sfarsit ce a inteles ultimul din lista. Nu vi se pare la fel si in cazul organizatiilor piramidale? Daca iau in considerare si complexitatea mesajului care ar trebui sa fie transmis, imi pot lesne imagina cum poate fi distorsionata o asemenea initiativa. E mai simplu atunci cand cei din virful ierarhiei transmit mesajul direct celor la care trebuie sa ajunga. Acum e mai simplu ca inainte, exista conferinte telefonice, discutii directe prin videoconferinta, bloguri, emailuri.

E important daca cei din echipa de management impartasesc sincer valorile pe care le asuma cultura organizationala sau le sustin doar din necesitatea pastrarii jobului. Exista si contestatari sinceri ai unor schimbari de cultura organizationala, care sunt indeajunsi de verticali pentru a isi exprima de fiecare data parerea contrara. Ce-i de facut? Ei bine, eu cred ca acestia trebuie convinsi si expusi unor experiente pozitive ca urmare a unor schimbari partiale in directiile enuntate. Altfel, vor deveni pasivi-agresivi - sabotorii de maine din interiorul unei organizatii aparent sanatoase.

Despre motivele unei schimbari de cultura organizationala, intr-un alt post...

Read More...

Do we have the right education? What about our children?

Read More...

Why bother?

Managing a team of software engineers is easy. Or not?
Being a software engineer usually offers good enough compensation, even the opportunity to get a senior position in a company.

Then, why bother to be the manager of such a team? This is my first question to whom ever mentions that she/he wants to be the boss.
Do you want to be there for the money?
Do you want to be there for the fame?
Do you want to be there for the power?
Do you want to be there for others?
I don't know exactly why someone should look to be a manager. There is no standard answer. But, I strongly believe that you should question yourself when only one motivation arises for this job.

If your answer to first question is yes, then you should look elsewhere for a job. This is usually the first sign that you will consider to reach the bonus by the mean of the team members. Think about looking down, as well as looking up (that is to higher management).
If you look for fame, than look around to see something also in the dark. Shining is good, but there are gems hidden in the corners.
If you look for the power... Well, this is the tricky one. Are you sure that you don't have something in addition to make the winning pair? I would be careful to work with you otherwise.
If you are there for the others, then be sure you don't forget the business.

If you are there for the job, than
                                                                              Good luck!

Read More...

www.elefant.ro

Am cumparat de 2 ori de pe site si am prins reduceri faine.
Sper sa le mearga bine, imi place si site-ul.

Sunt carti, la promotie si pe alte site-uri, cum ar fi emag, dar nu e chiar asa de usor de navigat. In plus, reducerile sunt mai mici si la mai putine carti.

Citit placut!

Read More...

tECHNORATI DIN NOU

38U4YMAGKC4Y

Read More...

Adopting a tool

Introducing a tool in an organization of software developers is not an easy thing.You need money, you need a detailed plan, but overall you need to see the new tool working and producing for your organization.

Get a sponsor or support from all shareholders!
So before announcing the change, get the support of the shareholders in your organization. 
Not all of them are fans of changes, so try to have a sponsor with enough influence to make this change happen. I dont know if the guy should be the big boss, the most respected technical guy, a manager just promoted in a new position eager to change things. Decide for your self.
But don't start without enough support from shareholders.

Get some profit!
Nothing works without a profit.
A new tools should bring with it some profit, either financial or in quality. No tool will be adopted if the costs for adoption are extremely high. The financial controller is constantly looking to figures, if you don't. No tool adoption should have as a result a red bottom line.
If the costs of work are higher, than it should result at least an improvement of the quality.

Ensure a nice journey
Every new tools involves an effort of learning. It's not possible to learn it over night, even Steve Jobs would demand so.
Invest in trainings and track the progress in know-how improvement. A good plan is not enough if you are not following it.
Sometimes the tool is not enough.People need practice, sometimes in a controlled environment where they are allowed to fail big time. Make this possible. Programmers need a sandbox to improve their skills, to make happen their learning curve.
Practice together with your team and note down the feedback. Don't overreact when the new shiny tool is not perceived the same as you do.


Make the tool loveable!
People genuinely have different interests, hobbies, tastes. They are different. And they have to use the same approach. Even more, programmers are geeks and they like their own tool. Not necessary their own implementation, but
Before going to announce the change in the organization, you have to know what is the general mood. For instance, if you have very creative people, oriented to fashionable tools, please think a detailed approach about how to introduce a tool with a dusty interface.
If this is possible, let them propose the tool. You, as a manager, just define the main constraints, the objective that you need to reach with this new tool. Team will solve the problem and they will adopt easier the tool.
Doing this definition of the constraints, you need to be sure that you understand the needs. Double check with team members if the new way of doing things is solving the problem or is just changing the layout of activities.
Having this done, create the urge of adoption. Evangelize the benefits of changing the tool and underline hard the disadvantages in current situation. Get as many supporters as possible.
People don't necessary love what they understand, but what is having a decent degree of charisma. Take iPhone and tell me what is understandable in the effect iPhone generated in sales. It's more about what the user feels. Remember, we are speaking here about a tool. Tools needs nowadays charisma.

Read More...

iPlan - planificare strategica de business

M-am inscris in programul iPlan, menit sa imbunatateasca comportamentele de planificare strategica.
Impresia pe care o am pana acum este excelenta si va recomand celor interesati sa va inscrieti.
Chestionarele folosite si feedback-ul pe care l-am primit pana acum sunt foarte "profi" si se bazeaza pe instrumente recunoscute (Strategic driver, Markstrat). Puteti gasi descrierea programului aici.

Va recomand sa va inscrieti. Puteti afla lucruri foarte interesante.
Este organizat de The Network, o firma de consultanta in management si marketing care aduna manageri romani experimentati.

Proiectul isi propune sa ofere instrumentul de diagnoza catre 3300 de manageri romani, iar cca 1000 dintre ei vor participa la 2 zile de seminar. Totul este gratuit, prin finantarea Uniunii Europene. Pentru mine, proiectul este unul care arata cum ar trebui cheltuiti bani europeni cu folos pentru Romania. Voi reveni cu impresii dupa intoarcerea de la seminar, in decembrie, chiar inainte de sarbatori.

Read More...

New adress of blog // Adresa noua a blogului

Hey, readers!
I am moving to a new domain.
WWW.CARTENOUA.COM.
Soon, a new logo and new posts.
Also, a short newsletter on weekly basis, if someone is interested. I will start only if I can get 15 interested persons.

Starting with Monday, 6th of November.


=============================================================================
Dragii mei,
Am achizitionat un nou domeniu pentru blogul meu.
WWW.CARTENOUA.COM
In curand, un nou logo si postari noi pe teme de programare si angajari.
Planuiesc si un newsletter saptamanal, daca voi aduna macar 15 adrese de email ale unor persoane interesate.


Incepand de luni, 6 noiembrie pe diversele ecrane (laptop, iPhone, iPad, smartphone).

Read More...

Estimations (not agile)

Why are needed?
Simply because you also need a deadline from your builder when the house is finished. And for sure, you ask for a delivery date when you go to your tailor. Plus, you ask for a price. No deal is closed without a price indication and a delivery date.

Simple tricks to make it better:
1. Read down what you have to do
2. Understand it
3. Split it in pieces.
4. Write down the pieces and think how much would you spend for each.
4.a. You have do in it and can look back in the history. Put the figures there.
4.b. This is the first time you have to do this. Split it in more pieces and go back to step 4.
4.c You cannot escape from step 4.b. Use your intuition. How complicated does it seems?
                        Same other task : put the same effort as for that, plus the learning effort
                        Twice as complicated: twice the effort plus the learning effort.
                        Five time as complicated than what you did so far: ask for another task.
5. Think a little about risks: what can happen to prevent you for completing the task. Put some effort there (not for all risk you identify, only for half of the big ones).
If the risks are to high, ask for another task or tell this to manager.
6. Sum it up and see if you can reach the deadline.
If this is not possible, then see what is the delta missing: can you speed up and delivery in time or is basically impossible and should tell this to the guy who requested this.

Read More...

UML in embedded (I)

I say now a truism. Model based development will be the new quantum leap in software development in terms of productivity.
It surely takes more years to adopt UML in the development, but there is a clear path to this.

Some directions:

• code generation (hard constraints) and documentation.
• UML meta models are the basis of AUTOSAR standards. AUTOSAR is heavily supported by most of car manufacturers.
• UML and re-use of software should be good friends.
• Round trip engineering tools are more and more available for embedded and ease the re-use, as the design documents are more readable.

More post on this in the near future.

Read More...