About Pelican Design & Development

By Arseni Mourzenko, founder.

Pelican Design & Development was a company I created in 2007 to support my career, first as a developer, then as a consultant. As a developer, my goal was to provide a broad range of skills in order to be able to deal with every aspect of a small IT project—something which was particularly interesting for small companies, unable to afford a team of dedicated specialists. As a consultant, my activity consisted of two things. Firstly, I trained .NET developers on different aspects such as programming in general, C# specifically, the different handy tools within or outside Visual Studio, and finally some specific aspects of .NET like Code Contracts. Secondly, I helped IT and non-IT specialists in working together, understanding each other, and performing their activity better in order to ship better software, faster. Productivity and quality are indeed two subjects I work with a lot, and write about both in my blog and on SE.SE.

Past activity


  • Customers     30
  • Companies
    consulted     20

  • Projects     80
  • Personal repository
    commits     6 400
  • Answers on
    StackExchange sites     1 200

Current activity

Pelican Design & Development doesn't exist any longer.

I closed the company because I had other interesting opportunities. However, I continue contributing, just like I did before, to the community, and I continue helping businesspeople who have some issues with their in-house developers, and developers who have issues with their businesspeople. Since I receive a lot of requests and inquiries, I believe it won't be useless to categorize them here and to explain what would be my possible response, in order for you to know whether you should contact me or not:

  • Can you do a website for me in [put your favorite programming language here]? No. Sorry, but no. I'm not a programmer. And even if I were, I'm not freelancing any longer anyway.
  • Do you know someone who can do a website for me in [put your favorite programming language here]? No. Choosing a right person requires a lot of work (which I won't do even if you're ready to pay me, since I'm not freelancing any longer). One has to know the context, the persons who will contribute to the project. The fact that I know a freelancer who happens to know your programming language is irrelevant.
  • I need a mentor. I'm ready to do mentoring. Your request is welcome.
  • I have an issue with my developers. If your team—whether you're CEO, CTO, team lead or project manager—experiences difficulties related to productivity and quality—that is they deliver late and the product is full of bugs—I may help. Since I don't freelance any longer, you won't have to pay for such “consulting”. However, you don't have a real consultation of a real consultant, but more a “friendly advice”, backed with my expertise and eventually a reference to half a dozen books written by very smart people.
  • Please, could you review my code? Code reviews are better when they are pair-reviewed. CodeReview.SE is a good place for that. If you absolutely want a review from me, post your question there, and send me a link.
  • Please, help me with my programming/design/architecture problem. I'm reluctant at giving such help, since my answer won't pass through pair review. StackOverflow and SE.SE are better places for that. Actually, you can get the best of both worlds: post a question on one of those sites, and then send me a link to your question, asking for an answer.
  • I want to use your product/package/diagram/article. Most content I publish is under MIT or CreativeCommons licenses, which are very permissive. Usually, the license is mentioned. If not, feel free to ask me for the details. If you need specific modifications, I may do the ones which don't take a lot of time and seem interesting to me. However, I won't be able to work for you, since I'm not freelancing any longer.
  • I need support for your product/package. I'll be lucky to provide technical support whenever I can. However, I won't be able to help if it requires too much time.
  • I want to contribute to one of your projects. You're welcome. What would probably happen is that either I'll migrate the project on GitHub, or give you write access to my SVN repository.
  • I disagree with your blog article. Where can I share my disagreement? If you want to talk about it with me, send me an e-mail. If you want to share your ideas with the world, use your own blog. As an example, Freedom of choice is my article written in response to Scott Adams' article.
  • Please, can you review my CV? I can do that, and I did that a lot in the past. You probably won't like it, as other people didn't like it in the past. Indeed, I find most CV astonishingly bad, including my own.
  • Could you hire me, please? Since I closed Pelican Design & Development, I can't hire you. However, if you're a talented IT specialist, I would like to know about you, just in case.

I'm still actively participating on SE.SE and will try to update my blog on regular basis. I also continue maintaining the open source projects I initiated, including Solange.

Core values

My professional activity is—and therefore my company was—impregnated by my core beliefs related to IT and software development:

  • Hiring processes are flawed in nearly every company, leading to poor choices resulting in teams which are mostly unable to develop successful products, even when their members may have the capacity of doing great things. A major effort should be focused on helping companies to understand how to do a better job at selecting talented people, and on helping candidates at leveraging their strengths and better communicating their values to the recruiters.
  • Working conditions for most software developers range from poor to terrible. Contrary to the beliefs of many CEOs, there are absolutely no reasons, including financial ones, to reject any improvement in this field. Developers who have to work in poor working conditions should insist at getting them improved; if the company remains unresponsive, there is no reason to keep working there.
  • There is a serious lack of focus in some crucial domains, such as interaction design, which leads to low quality products which don't fulfill well or even at all the needs of their users, while having a much higher cost.
  • A core set of practices should be used by every team of developers: version control, style checking, refactoring. Other practices, such as premature optimization, should be globally avoided. Aside from an in-depth knowledge of their programming languages of choice, developers should also have a set of basic skills in given domains, such as testing, deployment, requirements gathering, databases, security, performance, scalability. This is essentially what the term “T-shaped profile” is about.
  • The ability to learn is essential. Many developers I worked with were lacking the elementary skills, and most were far from being experts in their language of choice; much more disturbing was the fact that made no effort to learn. Therefore, every company should focus on increasing the skills of their developers, which could be done through formal training sessions, or internal training done by in-house senior developers, or even simple practices such as pair programming, dialogue and, not less importantly, involvement and contribution to the community through Q&A sites and open source projects, as well as book reading. The ability to learn should be demonstrated by candidates during a hiring interview.
  • Communication is an essential skill. Developers should improve their oral and written communication. They should absolutely contribute to the community, would it be through a blog, a Q&A site or a podcast.
  • Agile is great.
  • Flat organizations empower teams and their creativity. Hierarchical, bureaucratic organizations prevent them.
  • There is often a sort of fuzziness between IT department and people who, by their role in the company, are brought to take decisions. If those people are considering that they are skillful enough to take technical decisions and consider IT personnel as children who shouldn't left unsupervised, things will not go right in the company.
  • Long term matters more than short term. Too many companies are acting as if they won't exist in two years anyway.
  • Development is a mix of empirical evidence and gut feeling. It is essential to know when to apply one or another.
  • There exists no process that shouldn't be questioned. Too many meetings are plain boring and useless. Too many practices are blatantly illogical and harmful. Questioning the way a team thinks and acts could have a tremendous impact on both the happiness of their members and the productivity of the team.
  • Openness is great. Proprietary—would it be a proprietary format or a proprietary product—pulls the IT sector back by restricting or outright preventing involvement, contribution and collaboration. Most companies are buried deep in secrecy and spend so much time and money trying to protect their so-called intellectual property that they have nothing left to actually produce such property in the first place. In many cases, opening products to other developers would lead to amazing opportunities.

Those beliefs helped me to get better at what I'm doing, and promoting them through my career helped other companies to leverage the full potential of their people. Probably more importantly, it helped motivating some of my colleagues and let them see software development under a different angle: not as a boring activity of typing code the whole day, alone, following decisions of persons who don't have the skills to take them in the first place, but as a multifaceted, creative, responsible and inherently self-rewarding activity of creating quality products that other people truly enjoy.

Contact information

E-mail
arseni.mourzenko@pelicandd.com
Phone number
+33(0)698092766

Legal information