Edge of Chaos

There’s more and more buzz around estimates and #noestimates in software development. People like to write bold statements and go extreme about things in blogs. Usually, personal dialogues are much more balanced. Some hate estimates and believe it’s a useless activity. Some defend it with arguments of arguable truth.

I want to dig into intrinsic estimates complications, what people mean by “estimate” and what future directions we may attack → Read the article.

A couple of years ago I bought BMW 530 E39. Not that I’d been into BMWs all that much, but I just stumbled upon a good deal to replace my old car, and I went for it.

This car was excellent. I liked almost everything about it except:

1. The rain sensor. Even when set on the “High” speed it functioned very slowly, which rendered it mostly useless in the field conditions.
2. The front and rear windshield defogger/defroster controls.  Too far to reach.
3. The weird audio set controls. I had quite some trouble getting used to them.
4. Setting the in-cabin temperature with up and down arrows.

Then I bought the next-generation BMW E60.

Now, what do you think?

1. The rain sensor works perfectly.
2. They made the defogger/defroster controls bigger and put them to the center.
3. The audio set started to make sense.
4. They have knobs for the in-cabin temperature, and it’s just a pleasure to use them.

The smart BMW guys resolved all the issues I’ve been uncomfortable about.  But — of course — they added a couple of new issues instead:

1. In the E39, cruise control was located right on the steering wheel, and it worked just OK. In the newer E60 model they did it as a lame lever on the lower left side of the steering wheel, with absolutely non-intuitive movements to switch on/off and adjust cruising speed.
2. Door locks and hazard warning flasher switch were moved from beneath the driver’s right hand to the central console. For several months I’d start in the wrong direction to open the doors, until I got used to the new setup.

While the change #2 looks quite logical as it comes along with the new iDrive system, they have no mercy from me for the cruise control.

On the whole, the next-generation BMW remained the same, but better. I think that’s a very important principle for the evolution of any interface:

Same But Better

We’re getting at the good old issue of  UI novelties here. What’s better, slowly and meticulously improve the current system? Or introduce new elements in radical spurts, leaving no stone unturned in the old system?

Users are quite inconsistent creatures. For one thing, they like to download updates hoping they’d finally get the features and improvements they’ve been waiting for. On the other hand, they hate getting used to new features.

Any interface develops in cycles. Someone comes up with a new interface,  users start bringing in their feedback — that’s the stage of step-by-step improvements. One has to rework some parts of the functionality and mix in new features gradually, without having people learn from scratch.

Then, a critical mass of new knowledge is acquired over time, and if this knowledge is used wisely, it becomes clear how to improve the system along with the UI. That’s the time for revolutionary changes, and that’s how all interfaces develop (if they don’t die before their time):

new stuff → evolution → revolution → evolution → revolution → …

* rendered into English by Olga Kouzina.

I remember how eager I was earlier this year to hear what Phil, the prophetic groundhog, predicts about spring. There’s a special reason for that: as the name of my post suggests, it had to be published not before we felt something close to what it actually is about — joy spring!  Not even that much surprising, but Phil’s prediction turned out an epic fail, as spring got delayed beyond any reasonable standards. Finally, about 2 weeks ago, spring remembered about us, the freezing folks. Even Phil, the Groundhog, screwed up with his estimate, and while the spring is already far in, it’s high time to come up with a very fitting narrative of what missed deadlines, and deadlines in general, are about.

Apart from spring itself, there’s actually one more reason for joy. We’ve finally come up with TargetProcess 2.24, the spring 2013 release. The keyword is “finally”. We were supposed to be done with it much earlier. But it appears the release wouldn’t want to venture into the outer world in any other weather than the spring one (thank you, Phil).

Enter Deadline (escorted by Estimate)

Jokes aside, I wouldn’t be mistaken if I said that many meetings in software development are supposed to dissect the reasons for missed deadlines, or delivering later than expected.  I’ve been interested in studying the metaphysics of deadlines for quite a while (see my earlier post, it dates back to 2009). Now, if deadlines are in the spotlight of most meetings, which typical questions are supposed to be answered? And, what’s more important: even with answers to these questions in place, are we getting down to the roots of the real business “pain”?

Some of those questions would be: Why are we late? Why were our estimates bad? Maybe someone under-performed? The sacred holy deadline has everyone dancing before its altar like puppets on the strings.  It isn’t unfamiliar for people to have this nagging feeling as they come to a meeting and expect that someone’s head is about to be cut now. Especially if there’s the rhetoric of guilt and who’s-to-blame. It’s natural (I’d say that it’s unnatural) to assume that a missed deadline means we should chase and track down the bad performers.  As this subdued air of someone’s guilt or bad performance takes lead, and people focus on the “why bad estimates” part, you can throw the time that you’re spending at this meeting to a waste bin.

Usually deadlines are tied to estimates, like addicts to abusive substances. There’s no deadline without an estimate. If you’ve spent 3-5+ years as a project manager or a product owner or a Scrum master, or as anyone else who relies on the estimates of completion, you’d know that softdev work  can not be measured and predicted due to its very its own nature, at times even with no acceptable leeway margin. Ron Jeffries has summarized this rarely outspoken truth very well in this post (actually though, there’s quite some talk about the delusion of estimates at this  time).

Stunning. It appears one cannot rely on estimates, and can’t set a deadline, or predict a release date. With stakeholders, or marketing people, or clients wanting  you to commit to a time, this seems like an extreme nonplus. How do we go about it, and how do we persuade those stakeholders that life without deadlines is not only stress-free, but it actually means a better quality software at the end?

I think that this whole concept of deadlines is built on fear and insecurity. Something very old-fashioned and 19th centiry-ish. Okay, now if we have a deadline as a whip, our horses will exhaust themselves to get the carriage out of the mud and will deliver on time.  That’s a bit of an exaggerated comparison, but what else can come to mind if people are pushed to do something faster and to stretch their limits AND for no valid reason. Well, the reason appears to be very valid. His Majesty Deadline. If we miss it, then the Earth will sure stop turning, the sky will fall down on the sun, and the seas will dry out.

Deadlines have been inherited from the distorted ways of the 19-20th century fit for manual work. They’ve been dragging along like heavy but unnoticed shackles on our feet for 20-30-40 years (depends on where we start the countdown for the onset of knowledge work industries). Somehow the pedestal on which they have been sitting seemed steady like a rock, and it never or rarely occurred to people that deadlines are actually a mess. Or, a cautious tinge of a thought like “is that all a huge scam?”  would have meant going so much against the mainstream of  established outdated ways, that rarely did anyone dare speak up.

I’ve always been uncomfortable about the concept of chasing and being in a hurry to release. Ironically, if a release has been pushed against a deadline, and the horses have been whipped, funny thing, but it did become a sure sign for me that the harder the push, the less far off is the actual release date. That’s usually the case with what I call “subjective” deadlines.

Subjective and Objective Deadlines

Deadlines as a biological species in corporate environment can be broken into 2 subspecies: subjective and objective. The universal law that I’ve derived has it that about 90% of subjective deadlines can be turned into having no deadline at all. As for the objective deadlines, it’s harder to tame them, but there’s still a way.

A deadline is subjective:

1. For a small product dev company: there’s an emotional desire to come up with a new release faster for the sake of just faster. Usually, this is something that a stakeholder wants to do because he/she believes that this release needs to be out ASAP, or the company will  sink into the financial abyss, or the competitors will come up with the same thing that very day. Or — the real classics — the production guys have estimated that the release can be expected at a certain time, and marketing has made it public as the official release date.
2. For a softdev service company: usually service companies deal with the 2nd tier of subjectivity in deadlines. It all very much depends on their customers, and since how long have the customers been working with this company, and the bottom line: how much trust do the service company and the customers have in each other. This same situation also occurs in huge product dev companies, when marketing stakeholders plan rigid timeframes for marketing campaigns and activities, and devs are not involved in that. That’s the case of disconnect, and every party has to balance their needs and reality.

The objective deadline is this:

1. Something huge.  The Russians are now busy building the infrastructure facilities  for the upcoming 2014 Winter Olympics in Sochi. This IS a deadline. It can not be missed, and the Olympics construction projects can well be treated with the same intensity as the operations of the military.
2. The next possible instance is a grave event threatening the lives and well-being of people. Like, to rescue people from the flood that can wipe away their homes or from other natural disasters, or any other events like that (well, we’re very much into the movie crap of being immersed into all kinds of bad things, like saving the planet just on time before the aliens launch their rocket etc. so I’d let your imagination conjure up any other instances like this).

This is it. Just think about it. The majority of deadlines are subjective man-made disasters. Someone has said that human side comes a long way before software is made, and deadlines are not about the technical side but about people’s nature mostly. What I’m doing right now is breaking into the sacred sanctuary of “this-is-technical-you-know-nothing-about it” stuff with my liberal arts/humanities white gloves on, and graciously pulling all kinds of nasty misjudgments about software project management out of their holes.

No Deadlines?

My conclusion is striking. We tend to think that problems with deadlines have to deal with the technical issues and technical competence, and meekly mumble about who’s done/not done what as we look for justifications, but that’s not true. Once you’re in the environment of professionals, good rooted into the team, with good contextual AND open personal relations, then the problems float into the realm of how people make their point to each other and how they adjust to each other’s idiosyncrasies. For example, it’s beyond my understanding how endlessly can designers mull over a tiny UI element. To me it makes no difference. In their turn, designers or developers wouldn’t understand how I’m messing around an error message in the product UI. Or a piece of micro-copy. There’s no reason to be mad about it. In a way, we’re aliens to each other, and we can’t go any different than by finding a common language to share and understand our idiosyncrasies. Let alone the idiosyncrasies about design and copy, the most unpredictable part is software. You never know when you can stumble upon an unexpected impediment, ask any developer. Sure thing, it would be stupid to rush the developers knowing that they are competent, and they are working on the problem. This observation relates mostly to emotional deadlines, and is about the silent reciprocal understanding of why we get stuck on our way to the golden release date.

It’s nothing else than the issue of relationships and unity in an organization, to have marketing adjust to the reality of fuzzy estimates and deadlines. Looking at many companies, and at their release dates, I’ve noticed an interesting trend. Major releases usually appear either in spring, or by early fall. That’s quite logical: winter is winter, with its Christmas time,  the late fall is Thanksgiving, summer is the time when people go on vacation. This means, one can assume that late February-mid-March are expected release dates, but silently allow the possibility that it would really be mid-April-beginning of May. Or, for the fall releases, make it mid-August but really count on mid-September-October.

As much as I’m an opponent of  ”to do’s”, it appears I can finally commit to the one imperative how-to: Never push people with “when” unless it’s a matter of life and death. Only hearing this question might make them feel nervous (read, distracted from work and performing worse). It’s because of the ever-dragging legacy of the old-school insecurities, the clash of the need to give estimates and not being sure exactly of what is to be estimated, and the subsequent threat of being labelled as someone non-delivering to their expectations.

One of the things that can help with such questions and managers, though, should you encounter them in your life, is the intelligent “get done” forecasting. As in this report.

You can take these percentage probability forecasts, and show them to whoever needs an estimate of completion. If you’re curious, that’s one of the reports that we did in the recent 2.24 release. It can even work for service companies, if they have done the bulk of the enlightenment work about the fallacy of deadlines with their customers.

It might be hard to comprehend but unless we all become the beacons of the new no-deadline culture, we’d remain stuck in the outdated manual labor thinking amidst the technological progress of the 21st century. Take a look at this link. It’s a well-known Q/A resource for project managers. All of the questions tagged “deadline”, they have nothing to do with technical failures. Rather, people are not sure how should they manage communications and resolve organizational issues. Software development is more about humans as ever, since it’s getting still harder to live with no ecosystem of understanding and cooperation to replace the split reality of deadlines.

What is a Paradigm?

While there’s been some talk and research about project management paradigms e.g. waterfall, Project Management 2.0, ALM,  with the paradigm of agile prevailing at the moment,  looks like no one has spoken about the paradigm of project management tools.  What is a paradigm, in general? It’s a system of principles that unveils the essential qualities of a subject in their entirety. From this perspective, a paradigm of PM tools would be a spot-on framework for choosing a PM tool.  To make it more clear, a paradigm is something that allows a complete 360° view on any subject or matter. I’d say it’s not about the flat 360° view as in traditional geometry, but about a multi-spherical 360° view, as in the geometry of Lobachevsky. In linguistics, a paradigm is a complete set of all the forms of one and the same word realized  through declension and conjugation, esp. as in German or in Russian. A paradigm represents the system of approaches to unfolding a phenomenon. Musing about the cross-disciplinary nature of paradigms, how can we apply it to the project management tools, and how can this concept help software developers?

A multi-spherical abstraction

A Basic Paradigm: MS Project and Excel

I’m sure most of the readers have been facing the moment in their professional life, as they needed a tool for project management. Historically, most of us stem from MS Project and then Excel. MS Project served quite well as a clock ticker for the work that’s planned ahead and progresses exactly as planned. For waterfall, this narrow paradigm worked OK, assuming the project is flat and linear.

What changes in agile software development? The project management paradigm shift  means that nothing is ever going as planned. The PM tools should undergo a shift as well, from routinely tracking the progress the way it’s been planned, to dynamically sensing trends and registering hands-on performance indicators. Sounds like something familiar? Very close to stock trading, that’s right… and we’re still amazed at how many teams keep using Excel for agile project  management. Well, there’re some down-to-earth reasons behind this. Excel comes as a part of the MS software suite, and there’s no need to pay extra for it. One can put data to Excel, and even use it for planning, tracking and reporting. But there’s one essential flaw with Excel. It isn’t a shared collab tool, someone has to keep this Excel file, and while Excel shows statistical trends quite OK, as for stock trading, but it takes habit, skills and extra time to tune it as a decent trend-revealing tool for agile project management (and I’m not even talking about UX and visualization so far).

Excel used in stock trading

The Incomplete Paradigm: Beware Flaws in Assessment

There’re many project management tools out there. Tons of them. It’s not easy to navigate in this space, and when someone is looking to select a PM tool for their company, they  use some typical research methods… and bump against the same misconceptions.  Let me give a brief outline of some approaches that I consider counterproductive.

First, it’s following a direct pitch. Remember, what happens when someone throws a link at you and says “this tool is just what you need”? By “someone”, I mean people who send haphazard intrusive pitch messages either directly to your email, or in social networks, etc.  Normally you’ve got work that needs to be done right now, and you don’t want to interrupt your flow and switch to studying how this tool works, although it might promise a whole new world of  miracles. Next, you have no idea if the person who throws the link  is aware of your needs. It’s easy to throw a link at someone, but it’s not easy to decide for another person if that’s what they need. OK, you might be tempted to open the link to take a look, and invest some time in studying what it’s about. After taking a quick look, you decide that  the pains from using your old tool do not outweigh the trouble and time that you need to invest in exploring this new tool, and you stay with what you have. That’s why following a direct pitch is the least likely way to find what you need (and from the marketing standpoint, the direct pitches are rarely successful).

Second, it’s PM tool assessment sheets. I’ve worked with the leads and clients for quite some time, and what I’ve always been amazed at, that even until recently people have been using those cranky assessment sheets, that should be filled “yes/no” for random standalone aspects which would never put together the complete picture. Like, what changes if we put checks in all the boxes that say “collaboration”, “issue tracking”, “scheduling”, “portfolio”, “resource”, “document management”?  Such assessment sheets are clueless. They still give no clear picture of how the tool works, and whether it will address whatever needs and pains of this very company. The feature requirements as in those sheets  remind me of the flat geometry confined to the 2D surface. Somehow, they never have such bullets as “good data visualization”, “speed to change contexts and retrieve any data”.  That’s an apparent disconnect, where the task of selecting the project management tool is given to an administrative employee, and the real stakeholders, the people who will be working with the tool are left out of the initial screening stage. Well, might be that their process has the stakeholders engaged later, but why not then take a step of extra care to save the stakeholder’s precious time and add a few human requirements?  Like, how human-friendly the tool is? Is it easy-to-use? Still, as much as I’m a wordsmith, I have to admit that no words in no assessment sheets will replace the actual feel and sight of a project management tool in action. The complete paradigm of PM tools is supposed to cover all the facets of multi-dimensional chaotic project management, including the human aspect. How about introducing the criteria of learning curve – simplicity/complexity – user background vs. ease-of-use? One can’t make an accurate assessment of those qualities from “yes/no” sheets.

The third most common misconception is related to all the buzz around agile, agile training, agile consultants, “we-should-do-agile-coz-everyone-is-doing-it”, etc. It’s about hearing of the agile adoption, and rushing to get an agile PM tool, instead of taking care of the process first. This is the same as the phenomenon known as Gear Acquisition Syndrome among musicians, when instead of actually playing music people focus on acquiring lots and lots of music gear.

How much G.A.S. is enough?

I believe that if a company is building their agile dev process from within, they acquire their unique corporate expertise which is an asset in itself. It’s this unique expertise that finally helps them run projects with success and use the tools they need. Same with the GAS syndrome: you don’t know if you like this guitar until you play it. You can watch how a local  pro makes it out with the instrument in the show room (that’s what consultants do), or you can  try and play yourself to get the actual feel.

The Human Paradigm: Comfortable,Visual,Multi-Contextual

So, we’ve covered the basic paradigm of Excel, passed over the hurdles of the assessment sheets and the functional requirements – what else then do we need from a PM tool? We need it to be human-friendly.

A human-friendly data/information capture and delivery by a PM tool means two things: it’s visual, and it’s multi-contextual. I can’t think of anything that goes beyond this final layer.  A parallel layer would be  learning curve vs. ease-of-use, regardless of user background. That would complete our paradigm: a sophisticated PM tool needs to be pleasant to work with and simple enough so people can learn how to use it just by themselves, with no outside help.

There’s more about comfort and ease-of-use than we’d normally think.  Positive emotions facilitate cognition and reduce cognitive burden. When people  spend their time working with the PM tool that hinders their flow in one way or another, they get tired faster, and their higher cognitive powers “expire” faster. It’s not just a matter of pure design aesthetics or pleasant emotions. It’s about conditioning people to work more comfortably and successfully with software tools. We like nice architecture and pleasant interiors, so why should it be any different in the project workspace? The visual and omni-functional PM tool brings in a totally different quality of work for everyone involved, and I wonder why this human aspect tends to be overlooked by many. I’ve written more on the impact that software has on the human emotions (read, well-being and productivity) in the article Do You Speak Human, Software? 

Disclaimer: I didn’t mean to pitch any specific tools, or provide  reviews and recommendations, although it’s kind of more than obvious which agile PM tool is my favourite :)  My goal was to outline the paradigm to be used in the assessment of PM tools, and challenge some established patterns of thinking. When going off the beaten track, chances are high you’ll hit the bullseye of  your target board.. or process (couldn’t resist the pun :)

We are excited to announce a new major spring 2013 release!

TargetProcess 2.24.0 includes quite a few small and big improvements. Check what we’ve done to help you work better, faster, more comfortably.

10x faster search

We’re close to less than 1 sec search time, but this new search is not only fast. The search results look nicer now, and you can open them both in new tabs and as a pop-up.

Read more  about the new fast search in our Help portal.

Relations and Relations Network Diagram

Quite often one piece of work is “informally” tied to another piece of work. For example, the core team is working on an API, and the other teams are dependent on the core team’s progress. Keeping such informal dependencies in your head can be tiresome…

Starting from 2.24 you can track such informal dependencies right in TargetProcess as Relations!

Relations Network Diagram represents a network of related entities:

Relations can be created for any entity (i.e., user story, task, bug, etc.), and they can be of great help when planning or prioritizing. Be sure to check the article about Relations in TargetProcess Help Portal. It has more screens, and explains how Relations are helpful in planning and progress tracking.

New Visual Reports:Process Control Chart and Lead and Cycle Time Distribution Report

The Process Control Chart shows cycle time distribution for completed entities (user stories, features, bugs, tasks, requests) within a certain time frame. Check the screen below. If you see user stories between the warning limit and the control limit lines, this is suspicious. If a user story goes beyond the control limit line, this is really a bad thing, and you should investigate why it took so many days to complete. These limits are calculated statistically; they depend on the overall distribution of stories in the chart.

You can find a comprehensive description of the Process Control Chart here. It includes more screenshots and some examples on how the chart can be used.

Note the new powerful filters. You’ll see more of them later. They can now be used to filter out the entities in the Relations Network Diagram and in the new visual reports.

While the Process Control Chart quickly spots the entities that took too long to get done, the Lead and Cycle Time Distribution report helps you make realistic forecasts. You can filter out any entities, just as in the Process Control Chart:

Read more about Lead and Cycle Time Distribution Chart.

Improved Views

There’s a bunch of nice improvements to the views: quick convert (all the properties are kept intact for the converted entities), assign 2+ people, switch project quickly in the Info box for an assignment, auto-convert URLs to clickable links.

Besides, starting from TargetProcess 2.24 you can add up to 60 custom fields to any entity.

New History REST API

Check out the  new History API in TargetProcess REST API.
The new API will track state changes for Bugs, Feature, Impediments, Requests, Tasks and User Stories.
More info on the new History API in TargetProcess Help Portal

Most people like short things: short tasks, short emails, learn-how-to-program-java-in-24-hours books, lose-weight-in-a-month video guides. Modern society is cursed by impatience and time pressure. Information flows hit us from all sides and we just can’t resist. We spend more and more time on shorter and shorter things.

Software development demands focus. You can’t create anything significant hopping from one thing to another. That is obvious. Less obvious is that product development demands patience.

Service development is different. In most cases you have a project with a visible end. It may be a year long, or even several years long. But still project will be completed someday… Or abandoned. Most service products are sprints. Clients pay you money and they want to have something as soon as possible. They radiate the impatience. They set deadlines. They resist to invest much into good engineering practices like automated tests. Yes, you negotiate all that and sometime with a success, but still it’s quite hard to sell a great development process to the customer. So you rush, cut corners, drop some good practices to save time and argue about change requests. Agile approach helps to solve some of these problems, but you still feel the constant pressure. And rush anyway.

This strategy doesn’t work for product development. It takes a decade or more to create a truly remarkable product. Constant rework, constant improvements, constant polishing and learning. You fail, learn something new, improve things and move forward. It just can’t be done without patience.

Suddenly you understand that great thing takes time and it changes your attitude. You learn how to run with a steady pace, maintain energy level and endure the race. In a sprint you have no room for any mistake. Even a little mistake will cost you huge. In a marathon you have time to fix problems and still win.

If you are in a product development business, I can give you several advices:

• Learn how to learn. This road takes many years, you need knowledge to solve problems and invent things.
• Learn how to wait. It is so fucking hard to me. Sometime I feel enormous pressure to speed everything up and run at a full speed. But I realize that it will drain all our energy and development team will be exhausted and washed out. We’ll start to lose people. Morale will go down. That’s not a viable strategy.
• Embrace re-work. Most likely you will have to re-write some parts of the system 3-7 times in the next several years. You should be ready to do that. Re-work is good. It makes things better.
• Ship early. You may think that now I’m a 100% perfectionist who will kill for the 1px design mismatch in a latest release. That is far from true. I like to ship things as early as possible to some closed group of customers at least. For example, we are working on v.3 of our product during the last 15 months. It is still not public. However, we had first users 9 months ago. Currently around 600 people from 100 companies are using v.3, we have constant feedback and make improvements based on it.

Remember, that most people can run a 100 m distance, few people can run a marathon.

SVG background images have been  praised in many-many articles I’ve come across. Chiseled SVG backgrounds seem to be an unbeatable option indeed, from several standpoints.  But all the articles that I’ve read, they only briefly touched upon the performance issues of SVG rendering  i.e. it’s a more memory-consuming operation since  browser has to rasterize images anew every time.

So, one day I opened the web app I’m working on, and discovered that my browser is eating memory like crazy: it was about 600 MB (!) for just one tab, and even higher for a Retina screen. I went straight to investigate where this memory is leaking.

First off, I noted  a higher memory usage by a pop-up which rendered only as few as 20 icons.  Then I ran the profiler in Chrome, and found out that neither javaScript, nor CSS, nor HTML is to blame. I also noted that fewer icons take less memory. Plus, the icons are retrieved from a 2000 px X 500 px sprite image.  As I replaced the SVG sprite with a PNG sprite of the same size, a miracle has happened: the memory returned to reasonable limits. Obviously,  for each small icon a large  .bmp image was rendered, and it’s these .bmp images that eat the memory.

My first thought was — why don’t we give up on SVG? But it’s not that simple, you can’t just get rid of SVG and replace it with a .png, since we care about users with high-resolution screens.

I studied some articles and the specs on SVG, and decided to try em instead of px.  As I expected,  with relative font sizes, the memory ran as low as it would have been for a .png image.

Here’s the SVG vs PNG memory comparison (for 16 icons):

So, what can we do about it? The first option is to use two PNG sprites, one in normal resolution, and the other in Retina resolution. For SVG sprites,  relative font sizes, e.g. em, would be a better option.

After some more research, looks like this behavior is only observed in chromium-based browsers. Firefox, Opera and IE don’t have this problem. Of course, memory usage depends on the size of the canvas, and not on the font sizes being in px or em. But the sizes influence SVG scalability, so keep that in mind when choosing px or em for your particular case. If you care to take a look, we reported this issue to chromium, and it’s fixed now.

Further Reading:

www.webdesignerdepot.com/2012/12/stop-chasing-screen-resolutions/
coding.smashingmagazine.com/2012/01/16/resolution-independence-with-svg/
www.broken-links.com/2012/08/14/better-svg-sprites-with-fragment-identifiers/
www.w3.org/TR/SVG/
smus.com/canvas-vs-svg-performance/

*rendered into English and posted by Olga Kouzina. The original article is in Russian.

Another internal conference, Tau Conf #5, is coming up. These conferences are very special events at TargetProcess, and we look forward to them very much. Why? It’s a great chance to try your hand at public speaking with colleagues as the audience. People share something they have learned from their work, or something related. Gusto for knowledge, learning and sharing are the driving forces for our curious company. Besides, who says there’re no after-parties at internal conferences ..?:)

The only rigid rule for those conferences is: no third-party presenters. Everything else is flexible, as long as your presentation is of interest to the other colleagues. Everyone in the company can volunteer to do a presentation on some subject of their choice. Then we vote, and topics that get most votes are included to the conference program. Conferences are usually held in about a month after the voting, so speakers have enough time to finalize their presentations.

Here’s the program for the upcoming Tau Conf #5, scheduled for April 26th and May 4th:

We’ve done 4 internal conferences already, covering quite diverse subjects. That’s the Tau Conf #4 program from last year:

That’s the Tau Conf #3 program:

I’d like to write more about meetings today. It’s not a series of posts (officially), but looks like it’s evolving as one, since I’m picking up on my earlier posts on how to reduce the toxicity of meetings and how Skype works as on organic supplement for knowledge sharing  in our company.

On top of the usual UX meetings and dev kick-start meetings, we’ve introduced a new kind of meetings recently. The company board meetings. We’re just in this phase of growth when it’s about time to try boards for decision making.  At the moment, we’ve got the Product/UX Board, the Development Board and Marketing Board.  The founders/stakeholders board (the Head Board) has been in action for several years by now; this board is responsible for taking decisions about the company policy, some strategic visions, etc. It’s those 3 new boards we’ve started just now. The boards, usually 5-7 people, work by a simple 5-2 vote (or a 4-1).  The board members are of a mixed background: marketers and developers are sitting in the Product/UX board along with the UX people and feature owners (check who the feature owners are); developers and designers mingle with marketers in the Marketing Board. The good sign that confirms the integrity and the common shared vision of our team is that it rarely gets down to any other than 5-2 split-up of the votes. If it’s 4-3 or 3-4, this usually means that the subject requires more discussion, as some essential details might have been left out.

We’ve started the boards for several reasons. One of them is to be able to come up with unbiased visions. As a marketer, you tend to focus on the marketing things alone, so if developers infuse some of their blood into the veins of marketers, or if the UX people get involved in the decisions related to marketing — it’s good. From my experience, a more common case is when things are seen rather from the dev perspective, and developers need to be educated in marketing.

I’ve been at some of those board meetings but for the moment I prefer to keep a certain stance of cross-boardability. I try to make my point to people who sit in the board meetings, but I stay away from being too deeply immersed in the activities of any particular board. Why so? I have noticed one interesting trend. The boards start wearing out once they get into action (check the header image). It’s about the same, the more you rub the board washing your laundry, the more soap foam is generated, blurring the clarity of your vision. Well, this does not necessarily mean that the laundry will come out dirty, rather the other way round. But the laundry lady needs to clean the board from the used-up soap foam to be able to see if the laundry is clean. Not sure if someone actually does laundry this way — we’ve got washing machines after all — but, well, there’s no machine for the board’s decision-making, that’s why I’ve applied the soap-and-washboard metaphor here.

The intent behind creating our boards has been exactly that: to keep the vision fresh and clear, and consider things from all possible perspectives. Looks like some rotation is needed to maintain the freshness, and might be it has to be done more frequently than we supposed at first. Or, a fresh quick look from someone who is not a board member, but a keen observer could be helpful. If you’re not rinsing off the old soap foam, your vision will lack clarity and perspective, not to mention the notorious brain drain which would then creep in and poison your board meeting .  Perhaps, we need to come out with more sophisticated rotation patterns. Or, perhaps at some point, we might need to merge the UX/Product Board and the Dev Board into one Production Board. Or, make it Marketing Board + Product Board and UX Board+Dev Board. We keep looking and trying.

P.S. Happy 8th of March, ladies :)

In one of my previous posts,  I contemplated why meetings are exhausting, and uncovered a possible reason for that: people get tired naturally when they try to share too much within too short a time frame. It appears that asynchronous communication in between meetings helps to minimize this drain,  so I’ll tell more on how we do it in our company.

In general, this is searching for the most comfortable process of  knowledge sharing, which wouldn’t interrupt the personal productive flow of people and at the same time keep them informed just enough of what the others are sharing, in the context of each other’s responsibilities. One of the traditional ways of asynchronous communication are all kinds of comment threads – just like in this blog, if you scroll down a bit. We have the threads of comments built-in into TargetProcess, and they work mostly as status or diagnostic messages, like “changed the code”, “need the design”, “rolled out to production”.  For meetings and creative exchanges, something in the middle is needed. Not as slow as email, even not as slow as comments, but something that allows a delayed reaction and powers the dynamic exchange of ideas at the same time. Note, that I’m speaking only about the communication within a team of like-minded people here. Google Groups, Wikis – can you believe it, we even tried CampFire. Michael was tempted by its design, and decided it’s worth a try. It didn’t last long however. Just wasn’t as convenient as .. yes, you guessed it right, the good old Skype.

Whatever we tried, we ended up going back to Skype. Turns out it works best for our purposes, and in our environment. Of course, we’re not using it as an “instant” information machine-gun; people are not required to answer right away. We’ve set up a number of Skype chats. For example, there’s a “TargetProcess Design Folks” chat. The design people use this chat to build the collective taste in UX, they share links, discuss drafts and help each other come up with the UI concepts. I’m pretty sure, not any number of the formal UX meetings will cover the wealth of ideas and references that this Skype roll contains. So, for this creative exchange a Skype chat is a perfect tool. The only concern might be that every task has its due time: time to exchange ideas in the chat, and time to go deep into yourself to come up with your own thing. Fortunately, one can turn off instant notifications for Skype chats, or have the notifications sent out only if a certain word(s) is mentioned.

Among the other Skype chats, there’s one called “Product”. Anything related to TargetProcess as a product can be discussed here. Feedbacks, ideas, improvement suggestions, some of those suggestions can then be added to the backlog and implemented in TargetProcess. Our support and infrastructure team have their chat as well. Unlike the chats about UX or the Product, or the chats for various boards, this one quite often requires an instant reaction.

Skype chats are a good multi-purpose tool indeed. They provide instant notifications to support and infrastructure teams, and at the same time, they work as an optimal async communication tool, when it goes about ideas/knowledge exchange to back up the team thinking.  The consistency of this async exchange keeps everyone on the same page when at a meeting, and people are less tired. There’s no way one can stay completely fresh after a meeting, sorry, I wouldn’t commit to a “how-to” here :)

The more I think of it, the more it looks like Skype has the features that an agile team needs to generate ideas from the common pool, to react quickly, and to get into action. It might be that Skype won’t appear that universal for a company less agile than ours. I’m just telling about our experience.