Improvements Process

I had quite an insightful discuss today. One of those days when you stop for a moment to look at the point where your organization is. These are very valuable moments because for a moment you leave everyday approach (we’re fighting hard to complete the project; we’re improving that because it was all screwed up) and try to judge with no bias how things really look (we’re doing fine work but the project is still a piece of crap; improvements are huge but we’re still a hundred years behind the third world).

While typical mindset focused on the flow and those little improvements you do is essential to make constant progress, those flashes of true sight are needed to properly set directions of the process as a whole. While you can be happy with team performance and result of their work in a given situation, it doesn’t automatically mean all is set up properly. The chances are good you will find many flaws if you look from a distance.

OK, you have improved your KPIs of resolution time overrun for submitted issues from 600 days in a single month to 3 days during half of the year, but what about software development process? Unit tests? Nope. Code review? Nope. Formalized quality assurance? Still nope. Don’t be so proud then and go continue your job, you have still much to do.

Improvement process is constant, that’s nothing new. However, we often forget to make a little stop from time to time, take a deep breath and face the tough truth: how far you are from the finish line and if direction you’ve chosen shouldn’t be adjusted. It’s a bit like sharpening the saw. Discussions with former colleagues can be very helpful in that area.

And yes, there’s still pretty darn much work to be done here.

4 Ways to Tell About the Problem

Slips. Misunderstood requirements. Unexpected issues with technology. Problems with subcontractors. Lack of resources. Firefighting in other projects. Illness of key people. Mistakes in schedules. Lack of buffers. Delayed deliveries.

Everyday life of company which pays the rent developing software. It would be quite easy but, unfortunately, there’s a customer on the other side. And, what a pity, you have to inform them about all those problems. There are plenty of strategies.

1. Wait till they found out themselves. You eliminate unpleasant part of saying in front of The Big Ugly Client you’ve screwed. You delay a moment when the shit hits the fan. Unfortunately the shit is already big enough to make you really dirty.

2. Sell them some lies. There’s a chance they’ll buy your crap and nothing serious would happen. There’s bigger chance they’ll reject your crap and you’ll have to admit what the truth is. There’s the biggest chance they’ll find out what you’re trying to do and go mad. No one likes to be cheated.

3. Tell them but first prepare them. Send signals that actually there’s a chance that something possibly could go not exactly like it was planned. Wait some time. Eventually tell them, what’s really going on. Theoretically you should minimize client anger that way. Practically customer is often deaf when it comes to figure out your suggestions and usually you just delay a bit the moment when you announce bad news.

4. Tell them the truth. We sometimes call this tactic getting a knuckle sandwich. A scenario is simple – you go, you tell what has to be told, you stay calm when the customer sheds a bucket of animal dung right on your head and then you collectively try to find the way out. Besides rather unpleasant part with dung this tactic is fairly successful because you “buy” as much time as possible to execute emergency plan.

Personally I prefer the last option. I’m no politic and I’m poor at all those business games full of suggestions and signals. Negotiation skills aren’t on the list of my strengths either. On the other hand I feel well in situations when cards lays on the table and everything is clear. Even if that means telling tough things and taking all consequences of that. Like my mentor used to say in that business you need either tough backbone or tough ass. I think I have a bit of both and know how to make use them.

Long Life Old Programming Languages

SDTimes brings a nice story about not teaching programming languages like LISP anymore. That reminded me about renaissance of programmers knowing ancient languages like COBOL when y2k bug was coming and there were still a lot of working software written in those languages. Suddenly it appeared it’s hard to find a COBOL programmer and being the one can be quite worthy.

It still looks like a good idea for me to know some old-school technologies and become a specialist in that area of knowledge. I consider C/C++ as dying language. Yes, students are still taught C++ and yes, it’s still easy to find software written in C++, but developers generally prefer more modern languages (Java, C#) or those trendy ones (Ruby on Rails, Python). Finding a developer who wants to write in C++ is harder and harder over time, yet market demands significant number of them.

The easy reasoning here is: still much code written in the technology, few people willing to use it, should be worth to be a specialist in the area. I think it’s easier to become highly-paid specialist when you choose less popular technologies than it is with the mainstream ones. Anyway, developers somehow follow the trends and rather rarely take into consideration above point of view.

Hiring Mistakes

I like recruiting new people to my teams. I boldly think I’m not so bad at that. I admit to a list of hiring mistakes and I’ve seen many more. What I call hiring mistakes? Here are a few categories:

• Toxic. High skills connected with either toxic character or primaballerina habits. Those people look perfectly when you discuss merits during interview, but somehow they’re never team players after all. This is a tough one, because from one perspective the person is very valuable. On the other hand harming team work can never be justified by high skills.

• Theoretician. Read all the books on programming. Knows all the theory. Never written a bigger piece of code for a demanding customer. Quite often (but not always) these are people with university background. Very challenging in discussion but tendency to dig through all theoretically possible methods and lack of practical knowledge frustrates those who work close with him.

• Unable. No skill. No will to learn. No use for a team. Three times no. A dead end.

• No potential. You don’t always look for people with a complete skill set. Sometimes you look for one who will learn all things over time and then will become a fully-blown professional. And sometimes you end up with somebody who doesn’t have potential to achieve that. A dead end as above, but it takes more time to figure it out. Sometimes that’s just wrong career path set by a candidate and she can be moved to a position which would work better for both sides.

• Uncommitted. Good skill set. Good-natured personality. Yet somehow never committed or accountable driving team morale down every time people has to give a bit more from themselves. Can ruin team chemistry and atmosphere.

Do you know more?

No One Is Unmistakable

One of the most valued, non-monetary things in the workplace is to hear your boss admitting he was wrong. That’s not without a reason. It wouldn’t be valued so much if you saw that more often. And if managers were admitting they had been wrong every time they had you’d appreciate that the same as you appreciate the fact you can find the coffee in the cantina. Of course if you can imagine that, which isn’t the easy task.

People aren’t unmistakable and being a manger doesn’t make you one. A concept that you’re a manager because you’re wrong less often is, well, loosely connected with the reality. What more, counting per event, managers make significant mistakes more often. That’s not because their good decisions to all decisions ratio is poor, but because they just decide more often. Hey, that’s what they’re paid for.

Lack of ability to admit to be wrong, doesn’t help to build a leader position (as far as in your organization leader status is earned not just given). People see your mistakes, people feel you’re wrong, people know you should admit that. On the contrary, you can go out and say “Actually I was wrong and you were right. I’m sorry and I hope to listen to you more carefully in the future.” And then magic happens. You gain respect and trust, people become more accountable and willing to show up with their ideas, profits skyrocket, country goes stronger and everyone’s life is improved... OK, I went a bit too far.

The part of the problem can be character – no one, as a human, like to err. But we should expect leaders would overcome their personal fears. I really don’t care if my bosses can admit they’re wrong in front of their spouses as far as they can do it in front of their teams.

OK, time to print it out and pin it over the desk. The lesson is addressed to me too.

404 Error Handling

If you have a website it will happen. Someone will make a typo in the address. You will change pages addresses and old one will become outdated. People will just try to enter the page which isn’t there.

Will they see that?


Or maybe you’ve made some effort to keep them stick to your website for at least a bit longer. You ccould try to make the 404-page a starting point like on ProBlogger. Or you could redirect those requests on simple error page and than to main page like we do in on Overto site (sorry for Polish language, but it is Polish site). There’s an option to make a simple redirection to main page with no message in the middle. OK, there are heckuva lot of options and every one is better than leaving simple “no page, bagger off” message. Of course as far as you don’t want your users to bagger off.

The Power of Gossip

One of office games I used to play some time ago was injecting a fictional gossip into company and looking where it comes back from. It’s like injecting contrast medium to human body to see clearly on the X-ray how it is spread over the organism. I learned several conclusions from the exercise.

1. Never underestimate the power of Mighty Gossip. People believe what they hear and don’t really cross-check information.

2. Never underestimate the spread speed of Mighty Gossip. People talk with each other and share news which looks the most interesting. You meet persons who can keep the secret much less often that you think you do.

3. Secrets can’t be kept. Tell a couple of people something and you’ll hear that (possibly adjusted) from surprisingly different people.

4. The kitchen (or the smoking room) is the center of information. Go there and you’ll learn all the secret things.

5. The higher you are the less you know. People don’t talk with you. People don’t trust you. Sorry.

All those points teach the one lesson: share all information you can among the team. Don’t try to keep secrets among few people – just go there and tell everyone. If you’re stressed about the fact of telling people, your organization isn’t probably transparent enough and as a result people don’t really trust you much.

Sure, you can find news which shouldn’t be opened to everyone and you usually close them within specific groups (e.g. management). Anyway, the bigger the group is, the greater are chances something will leak and you go back to the point when you need to make your organization more open, honest and straightforward.

Wrike Review

It looks like we have more and more web tools helping in project management tasks. Another one, which was released a couple of moths ago, is Wrike. Wrike is (for now) rather simple application allowing to organize tasks in small teams. The application exploits different approach than the one used in Project-ON-Demand or OpenProj. Instead of following path of Microsoft Project they use fresh idea to base collaboration on emails, which are daily bread of project management.

General

Wrike is web-based tool so no installation is needed whatsoever. The application comes predefined so first thing to do is to clean default structure and create your own which is, I bet, completely different than proposed one. There is a weird thing to learn when you start working with Wrike – one of methods to add a task to your list is adding an email wrike@wrike.com to CC of email you send out. The concept isn’t a common one, but after a while you get used to the method. Of course there’s a “classic” method of adding a task using web interface, but, as authors state, real fruits are in seamless email integration.

In the area of managing tasks functionality is rather simple, editing task includes changing description, start date, duration, deadline and status. You can share a task or assign it to another Wrike user. You can see tasks grouped on simple Gantt chart. For the first public version I’d say that’s enough.


Issues

OK, time to rant. I guess I wouldn’t be me if I didn’t catch a series of issues in any software I play with. Wrike, like every fresh web-based application is an easy target here.

• Email integration. While I think the way Wrike is integrating with emails is a great idea there are several issues which discourage you to use that feature. I couldn’t find out exact rules of interpreting labels in emails subject field. Labels should define which group the task is added to, but it neither works like it was described nor like I expected. A bunch of emails I’ve sent to Wrike was lagged – tasks appeared after a couple of days instead after a couple of minutes. Maybe it was bad luck, but I wouldn’t consider reliability as one of main strengths of the application. If you use “reply all” option when answering emails Wrike dashboards of your team will soon be completely cluttered as every reply will add another task. Of course you can try to cut out Wrike email address from replies but you have to be a real optimist if you believe it can succeed. I couldn’t find a rule when the body of email is copied to task description and when it is not. Sometimes it works, sometimes it doesn’t. You don’t expect application would work just sometimes, right? Email integration is described as a killer feature and it has a potential to become one. Someday. Unfortunately, for now it is too buggy and unpredictable to be used as everyday tool.

• Setting up an account. Neither the activation email nor any other arrived to one of email accounts I tried to use to set up an account in Wrike. I guess it landed somewhere in spam bin on server side. I guess some adjustments in email are needed. On other accounts everything worked well.

• Tasks arrangement. Reviews of Wrike describe the application as “beefy” project management tool. Yes, you can find there a Gantt chart, but to manage a project (even if it is just organizing your own time) you need more than showing tasks on a calendar. Simple dependencies between tasks and arranging records on-the-fly are must-haves.

• Number of system updates. During several days of working with Wrike I’ve seen a few system updates. Each one required to log out and log back in. Well, it should be more seamless and less often.

• Invitations. That one is more about business model than about application itself. Sending any email to people and adding wrike@wrike.com on CC ends up with invitation to join Wrike sent to addressee. I know it help to spread the word but personally it a bit too offensive for me.

Cool Things

Definitely the coolest thing would be email integration if it worked well. The concept is fresh and simple, yet when you start using the model significant number of issues appears. There is a list of things which can be predicted: people would use “reply all” option, their email clients would add “RE:” and “FWD:” prefixes, iCal format would be used for invitations to meetings etc. Wrike should deal with all of these from the very beginning, but it looks like we need to wait a bit.

• Interface. User interface is clean and intuitive. I had no problems with becoming familiar with Wrike and most of key features are described in welcome video seen just after first sign in. Responsiveness for the web application is OK.

• Basic features. Functionalities which are typical for time management software are done well – I had no problems with tasks inserted from the web interface. Adding, assigning and changing tasks worked smoothly. I wish email-based features was working that well.

• Alerts. Alerts for changed, assigned, shared etc tasks works nice. Information is pushed to users’ inboxes so they instantly know what has been changed.

• Reporting. Reporting part is done well. Actually for me it’s even too expanded, but I’m biased in that area. I expect just the simplest reports, while Wrike delivers several different perspectives you can use to receive needed information.

My Opinion

Wrike presents approach which I like – start simple, add features users need. I think the big thing here is the idea of using emails as a base for task management. However that is the area which needs to be improved the most. On the first glimpse it looks easy, but it is not. Improvements are needed both quality-wise and functionality-wise. The latter case is more difficult, as I’d expect intelligent deduplication feature (for long email threads) better task management (closer to MS Project model) or task history (often treated as “enterprise” feature, but needed much more often). For now Wrike is more a collaboration tool than a project management application. Excluding email integration Wrike is rather simple software, like others you can find over the Internet (Basecamp is one of good examples).

I don’t really get all the pricing plans for Wrike. Where exactly is the difference between individual and group plans? I haven’t noticed functionality which is cut, yet the nature of Wrike can be exploited in multiple user scenarios. Anyway, you don’t really need collaboration software for a single user, as all the collaboration can happen in a head.

To be honest Wrike is not the type of application I was looking for. It is somewhere in the middle between serious project management tool and easy-to-use collaboration application. On the other hand Wrike has potential to go either way.

Shorten Information Chain

It happens all the time. Two programmers on different sides have to develop a piece of interface which integrates a couple of systems. It looks like that:

1. Customer’s Representative decides there has to be some integration work done. Vendor A is informed.

2. Here comes Project Manager from Vendor A. She agrees all the functional details.

3. Project Manager contacts Chief Developer and explains what has to be done.

4. Chief Developer finds victim er... Developer A who will do the job.

5. Developer A has a lot of technical questions (I mean a lot).

6. Questions are passed to Chief Developer.

7. Questions are passed to Project Manager.

8. Questions are passed to Customer’s Representative.

9. Customer’s Representative looks for someone from the Vendor B (deliverer of another system which is to be integrated) in panic. He finds Analyst.

10. Questions are passed to Analyst.

11. Questions are passed to Lead Developer on the B side.

12. Questions are passed to Developer B who implemented second system.

13. Answers are passed to Lead Developer.

14. Answers are passed to Analyst.

15. Answers are passed to Customer’s Representative.

16. Answers are passed to Project Manager (Vendor A).

17. Answers are passed to Chief Developer.

18. Answers are passed to Developer A.

19. Answers are vague. Darn. We go back to point 5.

In the meantime a bunch of emails was exchanged. A lot of time passed. Why don’t you just find a person who is able to understand enough details to satisfy all sides and let her bypass all other steps connecting directly with concerned developers? Why don’t you try to connect both developers directly? OK, with the customer in the middle it can be tough, but I’ve seen that so many times within the single organization.

I always try to shorten chain of information flow. Less hassle. Less delay.

10 Qualities of Good Developer

1. Perspective. Ability to look from business perspective apart from (typical) code-level perspective. Understanding why all the coding is done and where are the fruits for the customer/user whoever it is.

2. Questions. Asking why something is done that way. Discussing answers. Showing own point of view. Trying to be objective in the whole thing.

3. Communication. It doesn’t have to be great but you should be able to talk with non-developers in a way which is understandable by the other side.

4. Fallibility. Actually everyone is fallible, but not everyone is able to admit that.

5. Experience. From different situation, different systems, different issues, different architectures, different teams, different technologies, different environments. The more the better.

6. Learning. Will and ability to self-develop, learn (quickly) new things and adapt to new environments.

7. Digging. Understanding a problem to the very bottom. Trying to find out what’s happening under the hood. Rejecting easy trial-and-error explanations.

8. Reason. Every thing which is developed serves some purpose and using common sense one can easily decide which actions are justified and which are not.

9. Hobby. Treating development as at least something more than just a job. Will to do develop something just for yourself, not because you were forced to.

10. Quality. Just remember the quality is a weak point of software development and be willing to do something about your little piece of that crap.

None of them are actually about any particular technology. None of them is about any particular software development methodology. There’s no answer to specialization versus versatility question.

Things which differentiate good developers aren’t those which used to be considered as their core qualities.