replacing technology <T>

- never heard of T, is it software?
  - sure I've heard of it
    - I'm a big fan
      - tried it in a Hello World
        - use T daily
          - reported a few bugs
            - contributed to the code base
              - I am T expert consultant
                - I developed a parallel technology
                  - it's history, my technology simply wiped T out of the market

- What do people say about your pet project?
  - Don't have a pet project?!
    - Are you a software engineer?!
      - ... um, never heard of you, sorry.

satisfaction

It is a few months before a new Server Automation major release ships, so it's time to let the customers take a peek at what we've been working at in the last 6 months. We are taking them on a test-drive (but don't let them in the driver's seat yet) of the new features to get them to comment, like:) or dislike:( them.

But we got more than this in the last demo. The client was so pleased with the features we developed that this got them into a chatting mood, so some of us ended up pouring questions onto the client about their environment, how they use the product for their use-cases, how they horizontally scale their work (or not) when dealing with tens or hundreds of servers. It won't be far from the truth if I said that our questions outnumbered the client's. So yes, we got something extra out of it.

And the client got something extra too: as the discussion developed, they got their share of answers and tricks about the old features they've been using for a while now.

Still, we got more than the client did: satisfaction. Satisfaction cause they were satisfied. And it was plenty of it to share, to the QA eng that did the demo cause his clicks unveiled the magic, to the functional architect who spec'ed out the magic and for the handful of developers that ... built the magic.

Are you feeling down? Ask your customer to come in for a demo!

are you the next FA? (2)

Had a discussion a few days ago with my FA, and we came up with this shorter definition of an FA, looking not at what s/he should know but instead at what s/he should do:

The functional architect is responsible for specifying a feature so that it both satisfies the client and is implementable.

Wanting to be an FA? Then make sure you can look at a problem both from 1km and 1cm away. Be able to stay off and on the ground.

are you the next FA?

It was supposed to be a very concise post, but since these guys don't know what an FA is, why risk you being in the same situation?

Story short, this is what a functional architect (FA) is for me: mostly a BA as his main job is to create requirements, with enough field knowledge so that he knows how a feature would fit customers best and beat the competitors' feature, with the guts and power of decision to cut down on or to extend his ask, with good project timeline awareness so that he can add a touch of prioritization to his ask, with enough UI design skills to add a drop of color to his words, and an English phrase not to far from that of a documentation writer.

(... now my FA, he used to code a lot before doing this role, so he also sees my point of view and he knows very well the technical architecture)

How do you know if you're destined to become an FA? The first sign is that you take special pleasure in writing down the Expected behavior of a new defect you are submitting:

7

I'm a man of milestones ... so since 2006 I'm keeping track of the novels I read. Not the articles, blogs or profession-related papers and books, just the novels, literature. And it's a shaming seven novels per year. Good novels, famous authors, good Amazon ranking, but still ... seven. 25% of them are in English which accounts in part for the low number. Still ... seveeeen ?!

I then started this interesting exercise, of building from memory the list of novels I've ever read. Subject to memory loses, the list is still small, way too small. But doing the exercise, it felt good, it was in essence a review of an important aspect of my life. The list I built it's a snapshot to which to compare against in one year, two years, every year.

I won't set personal targets at this point, nothing like the one novel a month type, I'll just keep the list as a snapshot. And I'm going to think positive, low number but high quality. As someone dear to me said once, Life is too short to read bad books.

Here are two links you might find useful:
All Nobel Prizes in Literature
All TIME 100 novels

what is an API

It's about that part of the code that's exposed to the public, the public API ...

When you need to change it, you might have to go through an API review board. Generally they will reject any changes that will make the API incompatible with previous versions. Cause this translates to having all the clients of the API change their code against your new API version.

There are cases when keeping the API compatible will be so difficult and add/or so much technical debt that the review board will accept version incompatible changes. They will work with the field engineers to understand what clients feel about this change and with the PM so that the next product version (the one shipping the version incompatible API) increments its major number.

It's not only the changes to and the removals from the API that should be reviewed by the API, it's also the additions. If the additions are badly designed, you'll still have to stick to them in the future, cause that's what public in public API obeys you to.

Yet there is another type of change that must be brought to the attention of the board: not an API change, but a behavioural change. Why bother then? Cause while clients' code will still compile, it will stop functioning as expected any more. And the only way to communicate this is through the API documentation.

Here is an example: a login API that changes from querying the company ActiveDirectory in favor of OpenID.

We should stop thinking about the API as just a set of classes and their methods. It's also the behaviour that's triggered when using those classes and methods.

automated replies

Sometimes I find it hard and sometimes time consuming to compose an email: it has to say Hi and then at least a one line as introduction and then the real message, and then a signature. Should I write my job title above my name or they'd think I am too formal? Should I say Respectfully yours or just Cheers?

The format is something that emails sent by a software do not have to conform to. In the end who would think badly about some bytes that are not polite enough?! Instead the recipient will be quite accommodating with the message and more than this, grateful that someone took the time to code and set up a program that actually does notify people about things happening.

This is what I speculated on. After getting an invitation to a one-hour event that SDL Language Weaver is organizing in Cluj, this is what I wrote as a response to their confirmation request:
This is an automated confirmation email that I intend to participate at the event SDL Language Weaver is holding on Nov the 4th at City Plaza.

Funny enough, I've just received a Thank you message from their HR manager. There was no mention of my name there, so she must have sent an automated reply.