are you the next FA (4)?

It should have occurred to me much earlier to put it like this: what an FA really is ... it's the Product Owner in SCRUM ... bridges the gap between the technical and business worlds, OWNs stuff, takes DECISIONS!

And I am telling you: It has never ever been easier than today to take decisions in software!

And here is why:

1. We are encouraged to take risks. Risks may bring in failure. Goto line 2.

2. We are taught that failure is part of the game.

3. We are taught to embrace change, change brings in risks. Go to line 1.

4. Agile practices tell us that upfront planning is not the thing to do. Without complete upfront planning, risks are higher. Goto line 1.

5. There is so much complexity, so many unknowns, so much competition that getting it wrong will not be a surprise.

6. There is this notion of a throwaway prototype. In case your feature fails, declare it was a throwaway protoype.

7. There are so many other smart boys in the industry that simply could not figure it out!

8. Management continuously pushes us to innovate. Innovation leads to uncertainty, uncertainty leads to risk, goto line 1.

9. If you are working in an enterprise, high chances that you are part of a feature team. As opposed to component teams, features teams do not specialize in certain product areas but instead are mobile and take tasks in multiple areas of the product. This implies they do not own stuff, the ownership is collective. This implies collective risk taking. Thus collective blaming. But since management can not afford to send an entire team home ... you see my point.

So step up into this role. You'll have visibility, you'll be admired, you'll get your pay raise. Just be armed with the knowledge above for the 1:1 with your boss when you mess it up.

Take decisions. Or somebody else will. You're definitely smarter than somebody else!

the tools that saved the OS ... [2]

Fresh from MS Build conference, the Ubuntu on Windows project is along the lines of this older post of mine.

After this project goes live, it will be interesting to watch if the usage of Cygwin in Windows 10 will be lower than that in Windows 7.

I'm already used, you know?!

Every once in a while I come across a type that it is documented as being used by another type:

/**
 * Used by {@link SupremeCook} to bake supreme cakes.
 */
public class NewFlavor { ... }

As the author of a blog takes pride into having his posts read by many individuals, it would be the pride of the author of a type to have it reused as much as possible within the codebase.

Practicing over-documentation, the author of the type above softly coupled it with another type, defeating the above stated goal by making potential new users think the new type was not designed for reusability ...

3 years have passed by ...

Miles and miles away from our programmer, in a remote conference room in a remote part of the world, upon being advised by his lawyers, the young entrepreneur decided to withdraw the flavor packages still on the supermarket shelves to make the following correction to the usage instructions:

are you the next FA (3)?

Every now and then I can not help but admire what StackOverflow has become. Tricky errors scare no one anymore. Badges make you feel stronger than ever. People take pride in contributing there. Resumes display the reputation.

So if the word Functional in the job title Functional Architect is not music to your ears, and you long for the more handsome System Architect title, take note that it is the functional aspects that made StackOverflow what it is today, what made the difference between the other thousand forums with the same intent of helping users in trouble and StackOverflow.

the tools that saved the OS ...

... with no decent console.

... until some Windows lover coded Total Commander and another Windows lover coded Cygwin (although I have my doubts about the real object of love for the latter). Navigate folders easily in TC, script your day out in a *nix shell.

Here is a very simple and updated (older tricks here) guide of how-to open Cygwin in Total Commander's current directory (tested for TC 8.01 x64 and Cygwin 2.819 x64):

1. create a start menu command in TC and use the original invocation line the Cygwin installer uses:

2. add this to your ~/.bash_profile

cd "$OLDPWD"

Then you'll be able to use this power key (Alt + s + c, notice the &c in the menu title) to open Cygwin in your current folder.

get some drawing lessons

It was not my intention at all, but I somehow "stole" the best idea of the morning meeting today. To my defense, it was only the order of the speakers that determined that the good idea was first to be uttered by another participant.

QA practices around automated tests had to be changed, so we had to convince the QA manager.

At one moment, THE IDEA was uttered. By someone else from my team. The idea that would start to change the game. Beautifully decorated with solid arguments. Verbal arguments. Things became uncertain, the manager started frowning. So we threw in more words. He needed to think, he would come back to us.

Then I did the drawing.

The drawing that we looked at during the rest of the meeting. That we pointed at when bringing in more and more arguments. That made it my idea:

In the software world, the question is simple: can you or can you not draw?

in love with waterfall

Even if your company has forced you into SCRUM, if you are an influential team member or the mighty scrum master itself, you can find ways to keep your love close. Directly speaking, you can change SCRUM to still irradiate the warmth of the lost loved one. And it is even legal.

So I am suggesting you a new scrum but. Written by the book, it could say:

(We use SCRUM, but) (because we are in love with waterfall,) (developers speak first and only then testers in our daily stand-ups)

but it can be masked as:

(We use SCRUM, but) (because testers can not test unless developers develop,) (developers speak first and only then testers in our daily stand-ups)

I've seen this applied, so it's proven to work!

marketing

These two guys definitely think that marketing should be in the toolbox of every developer.

So you follow the above links recursively until you know everything about the two and marketing in general, evaluate how credible the two are, and then start to think if what they say makes sense.

And it does seem to make sense: market yourself, market your stuff! And then you think: Hold you horses, I work in this cube of this big corporation, there are others in other roles that will do the marketing, I can just code.

It happens that recently in one All-hands we've had, I've heard one of our PMs say something along these lines: We need to sell our new features to the Sales guys first, and then they can sell them further. And some time before this, I had heard our Director saying something along these other lines: We need to sell our product better to the Software org, so that it will count in the next product stack.

It all adds up, don't you think? But will a time come when you'll have to sell your stuff to the product director? Or to your manager?

... I don't think so, you're just a poor soul in a cubicle, right?!

let go (II)

To the one thinking about a software architect career, the bad news is that the LET GO advice applies to you as well! The good news is that it does not apply as drastically as for managers, so you might get your share of coding.

But what are the shares that you're "winning"? Creating a vision of the product, technical communication with the stakeholders, sharing the project risks with the project manager (agilists do not have a project manager role in their team and they are perfectly fine with that, no extra comments allowed :/).

I heard this guy saying yesterday that one characteristic you should look for in your next architect is that of being able and willing to step back. He was referring probably to stepping back in order to get the big picture. One other thing that he said was that he had seen cases when the software architecture was not properly looked after because the architect was too busy writing code and/or keeping up with new technologies.

This is what I'm saying! We should look for people who are also able and willing to let go!

let go

I can't help but giving out pieces of advice, probably a reminiscence from the times when I used to perform as a manager - yeah, I know what you think, hell of a coach, just an old fashion know-it-all manager. (Phew ... it's just struck me this bug of mine is what drove me to subconsciously start this blog!)

Anyway, today's advice goes to former software developers who embraced a management career and can't help but performing half of their time (they wish) as a developer and the other quarter (25% of time is wasted) as a manager.

LET GO! Just be a manager, your team needs you to take care of them, this is your most important task now! Why let go? Cause you can't afford it: besides the limitations that nature put on your intelligence, you are even more limiting yourself by focusing in two different directions.

easy svn merges?!?

Here is what you need to do to merge the changes from your long-living personal branch into trunk:

1. Back merge from trunk to your branch working copy

>>svn merge <svn_root_url>/trunk/<component>

2. Commit the branch working copy

>>svn commit -m "backmerge from trunk"

3. Reintegrate merge from branch to trunk working copy

>>svn merge --reintegrate <svn_root_url>/branches/<branch_name>/<component_name>

4. Commit the trunk working copy

>>svn commit -m "<meaningful message> ... <codereview url> ..."

5. Record-only merge to your branch so that you can continue using it

>>svn merge -c<revision_number_from_step_4> --record-only <svn_root_url>/trunk/<component_name>

6. Commit the merge from trunk
>>svn commit -m "record-only <rev_number> from trunk"

aesthetics

I believe in small increments: post a documentation bug here, correct a java doc or spelling error there, replace a Vector with an ArrayList when the collection is a local variable and you do not need synchronization, format a code paragraph. All this while marching on with your completely unrelated coding task.

Can't help it, but I always imagine a Grand Display, showing the product quality percentage, being run by a divine power that simply knows how to calculate it; and my change pushes that percentage up, indeed with a tiny increment, but still up, towards green.

Small and insignificant may they be, but the power of an entire crowd of developers doing small changes can be of a big importance to the product - a game changer long-term, for your next releases, for the maintainability of the product (something that the super power running the Grand Display did not teach us how to measure), because carefully crafted code and documentation will ask for code and documentation of the same quality level from the future commiters.

So encourage this practice to become contagious. Those that are likely to get infected first are those that can't help monitoring the source control commits. Don't think about your boss, but about the component owners with an interest in the component quality, the ambitious juniors that want to learn from others' code and those that want to make a name by finding other developers' bugs - all of them will appreciate your small increments.

Additionally, a trick to get more eyes to see your aesthetics changes is to include the files with small increments as part of the code review package for the bigger feature.

No, I am not preaching to occupy your time doing small changes - the vast majority of your time should go to changing the world. But big changes are never polished enough, so they will need the magic touch of small code increments.

one team for the customer

What have you done lately to make your customers happier?

Have you called them more often? Have you stopped developing new features until you reach a Zero Known Bugs state? Did you hire the best Information Engineers to make your docs all bright and shinny?

If a lot more than this, or none, or none of the above, let me give you another idea of what we do:

We built a cross-feature team staffed with the brightest people who analyze customer escalations, observe trends and write beautiful code to make sure future escalations in the area are near to impossible. Out of 30 customer escalations on how slow your server compliance checking runs, they would come up with a new way to access your compliance rule repository using a proven web server instead of your custom (slow!) python multi-threaded code.

How would this setup work? Would they sprint together with the rest of the teams? When will they sync with the feature teams to make sure they are not writing the same optimizations? Would you have this team on a permanent basis or build it ad-hoc depending on the number of current escalations?

Know what, these are all up to you, in the end it's the client 'smile' that matters.

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:

standards

There are 3 main languages in Server Automation: Java, Python and PL-SQL.

I am using this Java code

new SimpleDateFormat("dd/MM/yyyy hh:mm")

to format a Date object like this

day/month/year hour:minute

This is how I'd do it in Python:

time.strftime("%d/%m/%Y %H:%M", time.localtime())

and this is how I coded it in PLSQL a few day ago (obviously mislead by the two guys above):

TO_CHAR(_column_, 'DD/MM/YYYY HH:mm')

which resulted in me spending one hour starring at the same output '09:08'. For one hour I was tricked into thinking the business logic that updated the column was wrong. But the hour passed by and Oracle said to me: now it's '10:08', which lead me to think we were not speaking the same language ... definitely I was not mastering Oraclian (=PLSQL) properly: it turned out that if I wanted minutes, it should be MI and not mm.

For that hour ... someone should take the blame, what about the creators of one of these languages for not following the conventions set out by the others. It should be the ones that arrived afterwards, right? Or probably it should be the standard bodies for not getting into date formatting.

Or should I think that French sounds sexier than English, learn both and embrace the diversity? But I have not been acquainted to many sexy engineers over time ... so can we all agree from this point on that when I want the time printed ... it should be HH:minutes? I'm hearing they spell it the same in France ...

in an immature market ...

... interviewees for your job might ask you to double their current salary without any apparent reason except they want to change houses

Begging? Are you kidding? We'll live in a big house on Harbour Road. You, me and Salim, the three musketeers. (Slumdog Millionaire)

... interviewees for your job might ask for a significant raise just because the local currency went down and car prices are still expressed in euros

There's a lot of very important decisions into buying a car. So we have to approach it as mature, responsible adults. (So Little Time)

... there is a crisis of managers

Deputy Arnold. He took a seminar in crisis management last year. (Leverage)

... if you are a smart engineer and have some above average communication skills, your employer will want to make you a manager; change the employer, same story

Me? Why me? I'm nobody. I'm the supervisor of a Nerd Herd, at a Buy More. Maybe someday I'll be assistant manager. but I don't even know if I want that job. (Chuck)

... employees are titled "senior" much earlier; the employer has to be inventive and come up with more titles ... senior++?

Oh, yes, I remember this case. A high school senior at age 12. (CSI: Crime Scene Investigation)

... some software engineers change jobs every year or so and get raises with each move they make; employers, when will you start rejecting such candidates solely based on this criterion?

To kill an infidel, the Pope has said, is not murder; it is the path to Heaven (Kingdom of Heaven)

... 10+ years of experience in the same field and you're a superstar

Travis Colt. Our local superstar. He used to race for Nascar... (Death Race)

EDT deadlock

Many swing developers are probably unconsciously on the it-won't-happen-to-me side on this one, but I am the living proof that these things happen ... ok, once in a year. The bad part is that it can manifest for your clients running the latest Windows 2008 build, while your XP buddy will behave ok.

This is one of the situations when a debugger can't help you out cause your app is frozen, so ... meet thread dumps. Because most swing apps are consoleless, Ctrl+Break or Ctrl+/ won't work. But your smart IDE should help you take thread dumps; alternatively use <JAVA_HOME>/bin/jstack.

When your application freezes, you might be experiencing a deadlock, ex. when 2 or more threads are blocking each other, or it could be a temporary blockage due to resource unavailability. Let's go for the first case in this post.

Finding the buggy code turns out to be very easy: for a thread dump generated by the Sun JVM, start by looking for the string BLOCKED in the thread dump.

Immediately you can see the lock that this thread is trying to acquire, search for it in the rest of the thread dump.

It turns out the same lock was acquired previously, and in this case by the EDT. Moreover, the lock that the misbehaved "NGUI Thread Pool-2" thread is trying to acquire is a core swing lock.

The fix in such cases is (almost?) always making the code that tries to acquire the lock run on the EDT: go to the misbehaving thread, then backwards on the stacktrace until you can recognize some of your code. Then dig through it and decide on the place where the flow should continue on the EDT instead of your own (background) thread. You do the magic by wrapping your call like this:

SwingUtilities.invokeLater(new Runnable() {
    public void run() {
        <your call>    }
})

If you want to avoid such headaches altogether in the future, then play by the book ... and the book says:

Swing event handling code runs on a special thread known as the event dispatch thread. Most code that invokes Swing methods also runs on this thread. This is necessary because most Swing object methods are not "thread safe": invoking them from multiple threads risks thread interference or memory consistency errors. Some Swing component methods are labeled "thread safe" in the API specification; these can be safely invoked from any thread. All other Swing component methods must be invoked from the event dispatch thread. Programs that ignore this rule may function correctly most of the time, but are subject to unpredictable errors that are difficult to reproduce.

agile is not communism

I enjoy a lot articles that mix social and software sciences. And I think they provide much value to the software community cause software is built by people (still, as of 2010), so their psychology and their interactions drive the software development.

This is a lightweight reading for the morning in this respect: Agile is Not Communism. And even if the author does a pretty good job of proving there is not much similarity between Agile and Communism, this phrase stayed with me: Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either.

If you are like me and feel that today's Capitalism is not far from failure too, then take my advice and visit Greece, while it still has its islands ...

But since it's still early morning and we need our optimism for the day, take this quote from John Kenneth Galbraith: Under capitalism, man exploits man. Under communism, it's just the opposite. ... uhh, did I say optimism?!

next to binaries

There are not many things you can deliver to make your customers happy: one is definitely the code, and the 2nd are the docs: user-level documentation.

I've been recently asked to review the part of the documentation for the feature we are owning, and it was a surprisingly fun thing to do. I had no different feeling when reviewing it than the one I have when cutting some clever piece of code. It felt like putting the cream on the cake. It was an easy win: improve a deliverable that the client will definitely touch, cause our customers do use the documentation.

This line probably sounds right: good software comes with good documentation. But it's the other direction I am interested in exploring right now, what can documentation do for the code?

When evaluating new software I could use, like a web framework, those that have good docs have a much higher chance of getting in my toolbox. I start by looking for a section that would give me a basic setup fast, like Up and Running in Ten Minutes. Then I am awarding additional points for an introductory video. Then I will scan for How To-s for sensitive problems and references like configuration file and API ones. I admit though that once the tool is in my inbox, a weak online help won't make me drop the tool, as long as the help is not annoying.

For software developers good documentation means marketing. You'd want to grab market share, which for freelancers especially translates into increasing the number of users of the software. My advice is Write docs and keep them up to date, ask for reviews for even better docs.

Disclaimer: this post has not been reviewed before publication, hence it might contain some typos. No excuse though if it contains stupid ideas.