Similarities in Logos

There's one particular style (idea, flavor, expression) that I repeatedly see in IT companies' logo images. I like the way it looks though I think one was first and the others followed. It's hard to say if, in fact, there was a first one. It's definitely not a copyright violation to do things alike, not if you cross that percentile (is it 70%?) threshold that perfectly keeps a potential copy on a safe side. And then, the copy is very often not intentional. Think about music for a minute. There are, of course, borrowed melodies that were in fact knowingly borrowed (no one would admit but we know), but there's also loads of similar, sounding alike patterns, that one would recognize as matching one another with little chance to had been knowingly reused.

Here are the logo images that made up this post:




*

Do you see what I see?

I believe I have seen more of this "kind". If you come across a logo image that employs the same pattern, please leave a note and I will add it to my collection.

Cheers

* added to my collecction by Alex

How things sometimes need a little "kick"

It's amazing how some things need a little kick to get enough of my attention and motivation to make me spend extra time exploring them. It must be a special kind of a kick since some "forgotten" things get to wait years.

Almost always when I find a tool or technology that intrigues me I jump right on exploring it. Right away I'd give it a few minutes to a few hours of my time, I'd read about it, play around with it, do something with it. When I could not devote instant attention immediately I would save it for later, often print a few pages and take it home to read, or just put it on hold with a thought to get back to it the very next available moment. The time usually comes, sooner or later, though something of course I never get back to...

Powershell had to wait a long time to finally get through to me. I looked at it briefly when it first came out in 2006 and I thought it's great and definitely worth looking at. I downloaded it but then put it "on hold" ("refrigerate or freeze after opening") and never got back to it. I knew it was out there, I thought I knew what it was (it turned out I did not), but until very recently I had no motivation to try it out and see for myself.

Last week my son brought home this nasty stomach flu virus and we had a few very rough days watching him recover. Health care is extremely powerful these days compared to 100 year ago but we still can't do much about viruses. Too bad. Human body has to get over it by itself, the only help it can get is in fighting symptoms.

It's all long gone now, but when virus was still alive, Denis wouldn't sleep well. I had to spend half the night close to him just watching him breathe, being ready to help if he wakes up. They say, there are three things a person can keep staring at for hours, fascinated: a burning fire, a flowing water, and other people working :) I now know that a parent can do the same just watching his child sleep...

Then, I figured, this extra time staying up at night was a great opportunity to catch up on some of the technology innovations that I left behind unexplored and thus unknown to me. This is how I ended up spending a few nights watching podcasts and reading blogs - a luxury I rarely get.

This year PDC announced a few very interesting innovations. I already knew what's coming in C# 4.0 from Eric Lippert's blog though listening to Anders Hejlsberg was definitely worth the time. Then there was a demo of CCR and DSS from robotics. This one impressed me a lot. Very nice and clean approach to true concurrent programming (Erlang, beware!) that is not done on a language level but instead delivered as a library, pure managed code! The guys said it would make its way into the core framework one day. There were a few other very interesting videos including introduction to F#, and then I spotted "Powershell" in the keywords (I was selecting what video to watch by tags that appealed to me from this list).

- Kick!

There was 2.0 to the familiar name that I thought I knew but never really looked at.

- Kick!

It's not fair to watch Powershell 2.0 video if I didn't look at the original stuff; I figured I could not appreciate new features unless I knew old ones.

- Kick!

Enough kicks. Poweershell indeed wanted me to look at it. I had motivation and I had time too.

--

I knew that Powershell was a much more powerful shell language than the old good MSDOS batch, I knew it had pipelines similar to Unix shell, and this was pretty much all I knew about it. When I needed something really simple scripted I could use batch and do *.cmd. For more complex stuff I would use JScript as I did once for bulk visio backwards compatibility conversion automation. Powershell never came out of the freezer I put it in and I was missing 2 out of 3 its key features. I knew the pipeline but without the other 2 it was "just" a pipeline. We have a tiny little pipelie in regular cmd today (netstat | find "80"), so why get too much excited about a more powerful one? here's why:

• Powershell script operates cmdlets [command-lets]. It does not really have a "language" to it. Each command has a cmdlet behind it. And then cmdlet is just a .NET class that fulfills a few contracts. One can build a new one in a matter of minutes and register it with Powershell runtime


• but more importantly cmdlets operate with objects, "real" objects with attributes and methods. One command pipes in objects into another one and off it goes. The command implementation can read incoming objects, run them, do anything a language cmdlet is written in lets you do with objects.
  

Let me show you. As you can imagine Powershell does provide equivalents of well known DOS commands, ones like "dir". In Powershell it's now the Get-ChildItem cmdlet that can do any listings thru providers, not only filesystem, but it does not matter for what I want to show you. And one can do "dir" as Powershell supports aliasing:

PS > dir | get-member

what I asked Powershell to do is to explain me the objects that "dir" cmdlet returns. here's the output:



you see? now we can exploit the pipe, join a few other cmdlets, and do stuff like this:

PS > Get-ChildItem C:\2send\4Max | Select-Object FullName, Extension, Length | Where-Object {$_.Length -gt 1000}

or in a much simpler form

PS > dir C:\2send\4Max | select FullName, Extension, Length | where {$_.Length -gt 1000}

and then one can do:

PS > dir [..] | where [..] | copy [..]

and this is all very basic stuff! I bet one can do a much, much better use out of it. I now smile when I look at this post where I truly thought the dir /a /b /s > filelisting.txt was the nicest way of doing recursive filelistings :)

Next time I need to script something I will definitely try Powershell. If it turns out to be not as good as I now think it is I will make sure I blog about it. stay tuned.

Mastering Language

I am very passionate about mastering languages. It is true with both spoken and programming languages though this post is about mastering language we speak.

I admire people who can use the language in a way that freezes my attention, makes me read the text over and over again tasting phrases, feeling sounds and intonations, almost hearing the author reading the text back to me. As if I was listening with my eyes.

My native language and the language I speak at home with my family is Russian. First foreign language I studied was German. English came naturally with the profession and became my language passion. I live in the US since last year and all this time I've been practicing my language skills, working on they way I sound, and mastering vocabulary I use. The more time I spend with the language the better I feel how far I am from the place I want to be. Surprisingly, it's rather motivating and keeps me going.

I enjoy good reading. I don't have much free time to read and with a thick stack of professional things to catch up on I have even less time to read. Mix two lovely kids in (Denis is 6 and Alice just turned 1 month :), and here I am, constantly trading sleep time for at least some reading.

Fiction, I figured, is not always a good source of language enjoyment, at least not the enjoyment I wanted. While it might be great written it's often not the language I would use in my day to day life. Another thing is short time intervals during the day that I can fill with it. Do you like watching a movie with five interruptions when you pick it up from where you left it off the next day only? Neither do I.

So I picked up memoirs. It is apparently a popular type of writing these days and there are talented authors writing about their lives; some do it in a way that makes me come back to the same book over and over again. It's often not an easy reading but the language is well worth it. Some of the authors who I enjoyed reading lately are Augusten Burroughs (you may know him as an author of Running with Scissors though Dry is what I liked the most), his older brother John Elder Robinson and his look me in the eye, and Lucy Grealy with her Autobiography of a Face. You may question the contents and "Why on earth am I reading this stuff?" (my wife does :) but you can't argue the language quality. It's great, full of life, deep, entertaining, sharp, honest, Real.

--

When I come across a blog author who can do equal quality writing about technical stuff, who can give me both professional reading and fun reading, I feel jealous. It's a rare talent to be very good with technology and be able to use the language to describe what you're passionate about in a form that makes it fun to read for everybody while still delivering a unique value in content.

There's a list of Top 100 blogs for Development Managers. Almost everything falls into "my" category. But there's much more out there. This whole post was triggered by the blog of Eric Lippert who is working on the C# compiler team. Read his last series about C# 4.0features and reasoning behind it, excellent stuff.

--

I wish I had more time to write about things that I'm working on. I plan to do a series of posts about a modeling/configuration engine that I architected and built a few years ago. It got some attention recently and we decided to give it some uplift and maybe opensource it. We will see how it goes.

Personal Wiki [Continued]

A few days ago I wrote about an idea to set up a personal wiki space and how I was stuck at apparent big variety of wiki tools to choose from.

The choice really came down to hosted (thus available from anywhere) vs. local (thus available offline). I considered it for a while and figured that ability to work with my personal knowledgebase offline (say on a plane) was more important. And then if I need to I can host my knowledgebase out. Deal.

Next step was much easier than I thought. To pick a wiki tool for local deployment from a huge list of options I followed a simple selection process:

1. filter the list down to only tools that have been out there for a while (a few year I figured is Ok to secure product roadmap and stability) and have recently had fresh stable release (this year was recent enough for me)


2. must be open source and free


3. better not require anything I don't have installed (database, app server, etc.)

DokuWiki was my instant choice. It's been there for about 4 years, it's file-based so no database setup/configuration hassle, and it only requires Apache + PHP. Apache is always around and PHP was apparently in place too.

I have installed it 15 minutes ago and I am already using it. Dan gave me a good advice (though I didn't pick the suggested wiki tool) - "just start typing".

The best thing to do after you came across a thought to have a personal wiki space is to go ahead and create it!

Requirements

Martin Fowler has recently blogged on what he called observed requirement emphasizing the idea of web sites' users behavior observation as a powerful but yet not widely used driver of identifying and testing requirements. This post triggered two parallel thoughts in my head that I figured might be worth writing about.

#1: WebTrends and alike
#2: Different engagements warrant different approaches

#1. WebTrends and alike

The testing and observing part is not really new. "WebTrends and alike" is usually my first thought when I hear my customers want to analyze how their users behave on their web sites. The tool seems to be out there for about 15 years and for a good 2/3 of its lifetime we've been doing WebTrends-ready applications. What the companies then usually did with this was often limited to reporting. They would report on how did users behave, where did they drop off of the site, and what content was the most often requested/viewed. Sometimes they were even interested to see the most common user paths thru the site as they thought it might help building the right advertisement strategy. I recall one company did in fact want to include WebTrends(-like) support in order to test their original set of features and see if they could figure the best way to enhance their product thru their customers' footprints on their website. I can't tell if the "enhance" part ever happened (and my guess is it did not), but they had been working on content that they thought was "good" but apparently not proven to be so by the actual visits statistic.

I don't think there's an Approach to how to convert users' behavior into the site's feature-driver. It's just you can't see what's not there so you can't build a step-by-step guideline. The advice may be easier to give: leverage the instrument, especially if you are a company running your business on the web and competing in the SaaS market. Approach should be tangible, Advice may not be :)

#2. Different engagements warrant different approaches

Another thought that Martin Fowler's post triggered is not related to analytics. It's related to the intro quote Martin used to open his post. Martin quoted a "waterfalish" approach to requirements management and challenged it with the agile approach that is "...intending to discover the 'requirements' during construction and after delivery".

During last few years we as a company get more and more exposed to agile methods, agile projects, and customers who want to go agile (sounds close to the "go green" buzz). This whole concept of doing things agile and following agile principles in software engineering and software projects management is Great but is also often misinterpreted and misunderstood. The concept of "working software over comprehensive documentation" often gets translated into "agile means zero documentation". Does it? working software comes first. Yes! but who said zero documentation? The concept of "responding to change over following a plan" often gets translated to "we don't need requirements and we don't need to plan". Do we not? isn't sprint backlog a plan?

Different engagements warrant different approaches. One of the ideal environments for the agile project management (say SCRUM) is a product development project when the team takes on building a non-existing (or a new version of an existing one) product that gets elaborated on as the team progresses. It just naturally assumes close interaction with product management and demo-based turn-around. Integration project in a large highly-bureaucratic corporation where ten vendors have to cooperate and manage inter dependencies will naturally get very formal, and though can (and should) be delivered iteratively will have a lot of waterfall smell.

Consider how contract type affects the game plan. Another characteristic of the environment that well fits agile management practices is when the team is either in-house (e.g. business company running an internal project, ISV building software products for sale) or when performing organization runs on a T&M contract (e.g. outsourcing partner practicing Agile). Progressive elaboration to the extent when requirements get identified (not just clarified) as the system is being built is open ended in nature. Iteration cycle completes and produces an increment of the working product; the next cycle(s) will be driven by the priorities as of by then. Would you as a seller be happy to sign a fixed price contract without at least some level of due diligence on requirements? Would you rather want to build some requirements boundaries and document assumptions that would let you later be "flexible" and approach changes with a great agile attitude knowing your contract watches your back? I know what you think. I too wish I could explain all benefits of the "true agile" approach to all different businesses I get to work with. What an ideal world it would be.

Of course agile engineering practices are much less affected by the external environmental factors and writing unit tests as well as integrating continuously is like breathing regardless of whether you're up to building an internal product or a contracted vendor for one of the Blue Cross and Blue Shield licensees.

I'm slowly getting to what I was about to say here under number 2. Best practices are considered best in context. Requirements clarification and to some extent identification will be happening during construction regardless of your thoughts about it. It's the "art" part of the software construction. Though depending on the project environment you may well want to do a fair level of requirements due diligence upfront. Short on-site visit may be all you need. It will pay off.

And then finally a "requirement" can be very different. Without some level of "requirements" you just can't start the project, when existence of another level of "requirements" will only become apparent after final delivery.

Competence

...Core competence does not diminish with use. Unlike physical assets, which do deteriorate over time, competencies are enhanced as they are applied and shared. But competencies still need to be nurtured and protected; knowledge fades if it is not used. Competencies are the glue that binds existing businesses...

(c) Hamel, Gary & Prahalad, C. K. The Core Competence of the Corporation. Harvard Business Review, 1990.

Personal Wiki

I figured I need a personal wiki, a knowledge management and self-organization tool. I imagined a small personal portal that is a mixture of a wiki, a file drive, and a to-do lists management. Ideally a built-in mind mapping tool too but this one is a nice to have. I also considered whether I needed Outlook integration and decided I did not. I don't want to mix priorities. Outlook is my do-right-now-all-about-work tool and this one I target to organize my writings, readings, ideas, R&D topics, learning priorities, etc.

ok. where do I start? if you faced with a multi-criteria choice problem and you didn't know where to start what would you do? I thought I weight my criteria and start with the most important one. Wiki is definitely the key and if powerful enough may well end up being all I need. Great. what do you do next? Google.

do you know how many different wiki tools there are? I thought there would be a dozen commercial platforms and a few open source, some of which I thought might target personal usage. Who needs more, right? Take a look:

Comparison of wiki software

so where do I start now ?

PMP

On Monday this week I passed my PMP exam. It was easier than I thought. Though the process to get ready was rather long and that must have contributed to the easiness I now feel about the test process. I started off late in May and with a few weeks-long breaks in my study it's only October when I finally got to take the test. I should feel some sort of excitement I guess but the only thing that I can consciously feel is relief, a big one actually :)

I heard people say that PMP study was boring for them. Not for me. I didn't enjoy it, don't get me wrong, but it was not boring. Time consuming indeed, excellent sleeping medicine for sure :) but not boring in a sense when you do something because you have to and can't help but regret the time wasted.

What it was for me one might ask? Best of all, a way to systematize my knowledge and pick up on the right vocabulary and professional language. That is essentially the outcome for me, plus of course the label for the resume. People in PMI require project managers to advance in their careers and get better in the profession. So I can say I just complied with the PMI Code of Ethics and Professional Conduct :)

--

One of our executives approached me the other day and wondered why I picked the PMI certification and not some sort of "agile label", a SCRUM master or something else of that kind.

SCRUM, RUP and other life-cycle models / management methodologies for software development projects are specific to the software industry. PMI is industry-agnostic and does not teach a particular life-cycle model. Instead, it leaves life-cycle specifics to the particular industry and calls it "application area". PMI flies high above that focusing on major things and areas of concerns a project manager in any business domain should be dealing with daily. And it is in fact true. Person in charge of the project will be dealing with stakeholders, planning, scope management, risks, etc. In areas of quality management it lines up with ISO standards and CMMI models as well as Six Sigma. And again, it would be wrong to consider CMM/CMMI and ISO a development methodology, though I often hear people associating it with the waterfall-ish (less or more iterative but non-agile) model. But it's like apples and oranges, often cross-cutting and not necessary conflicting concerns. Primavera Systems, by the way, has their true SCRUM-based development process ISO certified.

Software craftsperson

It's well understood that the more cross-domains knowledge you have the better off you are as a specialist in a particular area. It's very true in software business.

I've always appreciated that I had a chance to start my IT career in a small software company where over a course of 3 years I learned and practiced all different kinds of programming languages and technologies. Never since did I touch as many different things (over the same period of time) delivering production software.

All extra time I had put in learning new things, extra effort I had spent jumping from one technology to another is now well paying off. It's an invaluable asset and actually a must requirement for R&D, technical presales, and projects' rescue missions (SWAT). The three things I enjoy doing the most.

Apparently, a few years ago Scott Ambler wrote about it in his Generalizing Specialists: Improving Your IT Career Skills. I somehow missed this one. It would not have changed anything for me as by then I anyway knew this is how it should be. It's just I haven't had a reference, I was unable to support my understanding of the way to develop IT capacity in a fast growing large software company with words of somebody who's well known and respected in the community, a thought leader. Now I have it and I thought I might share it with whoever follows my posts...

Cheers

Is doing Agile like having a jam session?

This post opens what I hope will become a series of posts on Agile in general and Distributed Agile in particular; about challenges adopting Agile in a geographically diverse environment; about injecting Agile in originally CMMI-oriented environment; all about running Agile with offshore. And to open a series I felt like I needed a metaphor, something to describe Agile in a new fashion, something fancy .

Yesterday I happened to be dragged into a chat in the office of one of our executives mangers (Alex, sales and marketing). People were talking about how to better position our experience and expertise in Agile.

Alex suddenly asked me a question:

- ok. so tell me. what do you do differently in your job [running projects and saving projects that are not going that well, to put it short] when you do it Agile? explain a fundamental difference to me without software jargon terms, make me understand it.

Then he paused and looked straight into my eyes. I felt like I really needed to explain it, and I wanted to explain it.

Think about it. There's no straight answer to this question. Agile manifesto declares principles that don't make (force) project teams do something fundamentally different from a "regular" (plan-based) approach. Iterative, continuous, open, transparent, collaborative, backlog, priorities, changes, test-driven, etc. - all this can be equally true regardless of the approach. I mean, we exploit all these techniques even in a big corporate high-profile, highly-political, and thus heavy on governance and formal processes accounts. None of this was the answer I was going to give...

- Hm... here's what I do different. I am actually always doing it but Agile setup just makes it very natural. Imagine me communicating with my customer (business representative, business analyst, architect, anybody) about requirements and priorities. I would listen to what they're telling me and actively engage in the conversation by running a funny background process in my head. I would convert what I'm hearing into a software abstraction, that is how would I build it. This abstraction is a very abstract abstraction - assumption-based pseudo architecture. It's like if I hear that there's a format conversion I can think "make it XML, there's always an XML-2-XML, we're done. doesn't matter if we end up doing it completely different, enough to know there's a viable approach that makes sense to me now." Or when I hear there's a report and tabular data I think "make it a relational model and I'll query it out, then slice and dice, we're done". And so on. If I couldn't build an abstraction I would ask for more details. Once I have a fuzzy abstraction that I'm comfortable with (I just need to feel it's feasible) I convert it back to the business functions to see the gaps in what I ended up with and what I was hearing in the first place. And here I would challenge the gaps and clarify the concept, redo the conversion, and go on and on in cycles. It's like I'm always actively thinking and building software in my mind as requirements get progressively elaborated on. I do the same in plan-based environment too, but I do it offline (!). In Agile environment I do it online. That's the difference.

And Alex gave me the metaphor I very much liked:

- so it's like jamming, like a jazz band having a jam session, true ?

here you go. It is like a Jam session, don't you think? The only thing is: you've got to be a damn good musician to do a remarkable jam session...

Using critical resources

For a short period of time a few months ago I was writing a lot of PL/SQL code myself on one project. I was covering up the team of 7 DB people who had enough Oracle knowledge but never really understood business domain so were unable to write effective hotfixes to patch a mission-critical system in production. And since it was often an Emergency threatening the very core business process of the customer (we replaced their obsolete core system with the brand new platform) somebody just had to fix it.

I maintained detailed To-Do lists of all items to be taken care of and was double-checking that whatever I’m working on is the most critical NOW. I knew I only have myself to rely on and I wanted to make sure I use my own capacity for the best possible value, understanding there’s no way I could do all of it. And as a result I knew that whatever I didn’t do during a day was less important that what I did do. See the point? there will always be something that will slip thru the cracks. And there may be a lot (!) of stuff. But as long as you know that it’s of less importance compared to what was taken care of plus you know there’s no more effort you could have put in – you’re good. As good as you could be, I mean.

Design Patterns

We have a very nice bookcase in our headquarter in Lawrenceville, NJ. It holds a few shelves of old books written five, ten, some even twenty years ago - all about writing software or using a particular software package or product. It really serves a purpose of a wall paper:) but I sometimes stop by and randomly pick a book and flick thru the pages reading paragraphs here and there. It either fills a little break that we all sometimes need to keep ourselves concentrated and focused, or just a spare minute when I'm waiting for someone to have a meeting and don't want to go back to my office when I know it's really a minute or two I have at my disposal so cannot really do any concentrated thinking.

Today I picked the "Pattern Hatching: Design Patterns Applied" by John Vlissides (1998) and here's a quote of the day:

------

"Misconception 5: Patterns guarantee reusable software, higher productivity, world peace, etc.

This one's easy because patterns don't guarantee anything. They don't even make benefit likely. Patterns do nothing to remove the human from the creative process. They merely bring hope of empowerment to a possibly inexperienced, perhaps just uninitiated, but otherwise capable and creative person.
...
Patterns are just another weapon in the developer's arsenal. To ascribe much more to them is counterproductive. Underpromise and overdeliver - that's the best defense against hype and backlash."

------

It's well applicable to nowadays' "patterns" too. SOA "pattern" was the one I thought of immediately after I read this.

Syntaxhighlighter

In April 2007 I blogged on the way to colorize source code postings.

...I was thinking how great it would be to have a CSS-based solution so you can put your source code into HTML element, define a few style attributes, and let it automagically colorize everything. wow...

I explored an idea (rather as a fun experiment) of building a DHTML behavior that talks to a server application, passes the code fragment, and replaces the page content with a formatted HTML fragment upon response from the code formatter application.

Today I ran into a Google Syntaxhighlighter that seems to do exactly what I dreamed of and as I can see is available since almost exactly back then, just one month later. It explores a different and a much more "down to earth" idea of parsing the code with regexps. Nice isn't it?

I'm Back

back online posting after more than a year of silence. Not that I blogged much before but I guess I may do a little more this time. A lot happened since my last public appearance: we moved to the U.S.; had two very nice vacations (one winter-time in New Hampshire skiing for the first time in my life and one spring-time in California where my family joined me on my business trip to eBay); finally decided and put on dental braces; watched my 5 years old learning how to ride a bicycle - he did it so well I now barely can keep up running when he rides; helped one big offshore team to release quite sizable and a pretty crazy project to production and by doing so wrote more code than I did in two years before that; got pretty tired mentally of helping that team sustaining that crazy project in production so started learning how to paint and amazingly for myself did pretty good at it; decided to finally pass the PMI PMP and now look forward to do so as soon as I'm done refreshing my memory around PMBOK; received my first ever tax return; and got lucky with my 4th submission to DV lottery.... last but not the least - we're now expecting our 2d baby. wow...