Polish government has been offering grants of up to £200,000 for new startups as a part of its Innovative Economy programme. They’re easy to get, beneficiaries are not evaluated according to their likelihood of succeeding as long as their business plans meet certain predefined criteria. They’re also not held accountable if their business ultimately fails. Sounds like a good plan? Don’t think so.
Those grants teach aspiring entrepreneurs all the wrong lessons. They open up a possibility to get interest-free non-repayable business funding with no (or very limited) accountability. Business plans are evaluated by clerks with no prior investment experience, VC or otherwise. How are they meant to be able to asses whether your project is a good idea and will turn a profit?
This explains why the failure rate of those businesses is so high—people apply for grants because they’re available and so easy to get (why would anyone pass on such an opportunity?) without even thinking their ideas through. They burn through the funds over a couple years and close down shop with no ideas how to turn it into a real business. No questions asked.
The Innovative Economy programme seems to be doing more harm than good. We’re raising a generation of wannabe-entrepreneurs who think that someone else will always be paying their debts and fund their ridiculous ideas. Each year millions of euros are being wasted whilst the government and the EU are patted on their backs for creating equal opportunities for everyone.
The majority of business funded through this programme could’ve easily been bootstrapped, making their founders think twice before spending every penny. The remaining few which required high startup capital (e.g. hardware companies) should have been looking for private investors which would not only provide necessary funds but also advice and guidance.
Luckily not long from now the programme will be over and maybe then people will realise how bad an idea it was in the first place…
We are always looking for ways to streamline how Object Reload is run and going completely paperless is one of the things I always wanted. 2011 might just be the year when we make that happen.
We already do most of our business electronically, but here are some areas that have been a problem for us in the past (or still are):
- Contracts - Invoices (to customers and from contractors) - Bills - Other (including snail-mail)
Let’s see how we tackled these and what’s still left to be done.
Contracts
Back when we started in 2009 all contracts we signed were paper-based, both for our customers and for our contractors. We’d have them printed, signed and shipped, taking a significant amount of time for all parties involved. Worse still, our developers’ contracts used to be renewed monthly, generating even more paper work.
At the beginning of 2010 we decided to move to annual contracts for our partners. It was a 92% reduction in the number of documents exchanged, but still not something we were satisfied with. So in late 2010 we started experimenting with RightSignature, a great tool for online document signing. We’re now using it for all customer and supplier contracts, no paper involved. This not only helped us sign contracts much faster, but at the same time provide a better experience for our customers.
Invoices
This is a big problem for our Polish branch—local law is very restrictive with respect to electronic invoices (you need a qualified digital signature) and very vague about sending PDFs by email. Therefore most invoices we send and receive are still printed and posted, although we do send them by email first. There’s definitely a lot of room for improvement on that front.
Invoices from our contractors used to be dealt with in the same manner, but starting this month we’ve switched to RightSignature due to slightly less restrictive laws when dealing with individuals as opposed to companies.
Bills
For the reasons outlined above, most utility companies still send paper invoices and there’s little we can do about it. Our previous mobile operator used to send us e-invoices, but since we switched to a different one it’s no longer an option (note: they e-invoice individual customers, but not companies).
Other
We use a number of tools to help us run on as little paper as possible. We use Basecamp for managing projects, Backpack for knowledge-sharing and Campfire for real-time chat. We also rely on Dropbox to keep all documents in sync between me and our office manager.
Most mail that comes in either needs to be kept for legal reasons or is shredder/thrown-away anyway, so we had no need to digitalise it all, but I’m revisiting that topic to see if we can minimise the number of documents stored even further.
What to do next?
First and foremost, we need to find a workaround which will allow us to go completely digital with invoices. This is still a major flaw in our system and we’re not giving up on trying to fix it. Bills and other documents are already limited to a few essentials, but I want to cut back even further.
What are your experiences with going paperless?
If you have any experiences, good or bad, with going paperless or any tools that you can recommend, please share them with us! Email us, stalk us on Twitter or visit our Facebook page. We appreciate all your comments.
We’re happy to announce that for the past two months we’ve been helping Nurph bring to life Twitter’s missing group feature and enable you to chat with your Twitter community in real-time.
What is Nurph?
Every Twitter user needs a place to bring their friends & followers together to chat, and that’s what Nurph Channels do best. Extend the conversation by chatting in real-time with your Twitter friends whilst your followers can watch.
We believe they have the potential to be one of the hottest startups of 2011, so make sure to check them out or follow their blog.
Who’s working on Nurph?
Kudos go to Szymon who’s been working closely with Neil (the founder of Nurph) to bring to awesome product to you.
2010 has been a tremendous year for all of us, for which we are all very grateful. We’ve established some fantastic partnerships, helped launch and maintain amazing products and the outlook for 2011 is even better!
We’ll be making some exciting announcements in the first quarter of 2011. We’re on track to launch our first in-house product and are dying to share it with you. It’s been a roller-coaster ride with many ups and downs, but we’re sure it’ll be worth it. Stay tuned for more updates on that front.
I hope 2010 has been a phenomenal year for all of you as well. But hey—2011 will be even better, right? Let’s make is so!
The Cambridge Student has recently profiled (p. 16) Mateusz and asked him about his academic and business careers. In his answers he describes how he developed his passion for building intuitive software, what inspired him to start Object Reload and how he manages to run the company whilst completing his degree. Read ahead for the full transcript of the interview.
Q: What are your favourite places to visit in Cambridge?
A: I always enjoy winding down after a busy week by going to Starbucks and
reading a good book, especially earlier in the morning when it’s still quiet and peaceful; or just strolling around the city, admiring the architecture and looking for inspiration.
Q: What is the most unlikely skill which you have learnt while at
Cambridge?
A: It would have to be appreciating free time. I learnt to schedule a few
hours a week just to clear my mind of distractions and reflect, which is something I would have previously considered a waste of time.
Q: How good is Cambridge at supporting your software design activities?
A: Computer Science here is very theoretical, so the majority of courses
focus on things which have no direct application in software design. Nonetheless, there were a few opportunities which enabled me to pursue my interest in software design and verify what I’d learnt from the experience of running a software company.
Q: Were you interested in software design before arriving at Cambridge?
A: Definitely. Software design has been my passion for a long time now,
having started freelancing when I was 15. I love building software which helps people solve real problems and this has inspired me to start my company—Object Reload. We believe software should be easy and intuitive and try to focus on making everything as simple as possible, but no simpler.
Q: Does your academic work ever conflict with your extra-curricular
commitments?
A: I would like to think that I can stay on top of commitments rather well.
Juggling academic work, rowing and running a company can be hard at times, but my passion for simplicity has enabled me to streamline things as much as possible. I try to read email only once a day, hand over day-to-day running of the company to my Executive Assistant and spend a fair amount of time each week thinking how to make things less complicated and make better use of my time.
Being a software company, often times we discuss with our clients their reasoning behind particular features they want us to build into their applications or websites. It helps both parties clarify the business value behind it, resolve any misunderstandings and misconceptions as well as work on alternative solutions should they be needed. There’s only one argument we dread more than anything — “because of SEO”. Let us explain why.
Reading the tea leaves
SEO is nothing more than that. One may argue that it’s more like fine-tuning a system by carrying out small incremental changes, analysing their effect and figuring out whether they did the trick or not. They’re wrong. Google’s algorithms are way too complex to be beaten just by looking at them from the outside. Your conclusions are likely to be drawn from false assumptions about what you think influenced the ranking on a given day.
Still thinking that those few extra links you stuck at the bottom of the page and all those keywords you threw into that article, making it completely incomprehensible for human beings, gave you that last boost in Google? Think twice — it’s more likely that your page was simply liked to from a few more pages and voilà — you’re up a few spots!
Optimise for your customers, not Google
How would you feel dining at a restaurant where food is optimised for industry critics and reviewers who, for example, happen to like over-salted fatty food with little nutritional value, but since that’s what they give good reviews for everyone is served this crap?
That’s exactly what SEO is about — pleasing Google at the expense of your customers and people who actually care about the content on your site.
Our rule of thumb for SEO is remarkably simple — if it doesn’t improve usability, you’re doing it wrong.
Focus on what’s important
Snap out of this delusional thinking and check again who is paying your bills. I doubt it’s Google. Focus on making your clients happy by optimising your site for them and they’ll spread the good word.
SEO is about quantity, not quality — would you rather have those extra few visitors you gained by trying to outsmart Google or a dedicated customer base who is enjoying your product because you care deeply about them? For us it’s a no-brainer.
Leave clever tricks to Google
Google is one of those places where cleverness flourishes in its purest form. They employ some of the most talented individuals on the planet to get search just right, so take your smart-ass hat off and let them figure it all out. They’re doing their best to promote sites which bring quality content to the customer and demote those who don’t.
Focus on improving yourself and making awesome products, and believe us — you will reach the top sooner rather than later.
It doesn’t take a genius to realise that testing is a very personal matter. From Test::Unit purists to RSpec evangelists, everyone has their own take on testing Ruby code. And whilst we believe that not only there are no silver bullets in most of the problems in software development but personal preferences make it unlikely that there will ever be any, we’d like to share our thoughts about testing in this series of posts. We hope it will be as enjoyable for you to read as it was for us to write.
Consider using Test::Unit before delving into third-party frameworks.
There’s nothing wrong with the plain ol’ Test::Unit. In fact, choosing it over fancier solutions such as RSpec, has many advantages.
Firstly, you’ll have hard time finding a Rails developer is unfamiliar with Test::Unit. Using it in your projects guarantees minimum hassle when swapping developers between projects.
Whilst RSpec-like syntax offers some sugar candy it can be quite misleading sometimes. Consider the following two examples:
The first test will always pass, regardless of the value of @post.author.points since 20 evaluates to true. Apparently mistakingly writing assert instead of assert_equal is quite a common fallacy of Test::Unit, often cited by RSpec enthusiast. It is not uncommon however to encounter the second example in an RSpec or a shoulda + matchy test suite, where a similar mistake is made by forgetting to add .should before the comparison.
Nested contexts make writing tests easy, but reading them tough as hell.
It isn’t unusual to find between 10 and 15 contexts in a single test case. Each with its own setup, some nested three or four leves deep, yet sometimes containing only a single test. We found those test cases to be extremely unmaintainable, especially when you’re trying to figure out which setups apply to a particular test. Keep your tests as flat as possible (or don’t use contexts at all) and avoid deeply-nested setups at all cost. Don’t worry too much when you repeat some code in your tests — DRY is great for your application code, but tests need to be readable first and foremost.
Don’t get all touchy-feely with your database. Save records only when you
have to.
Avoid saving records in setups — saving your records in unnecessary in the majority of your test cases, especially when you’re dealing with validations or properties which can be tested without ensuring database persistence. Save your records only when you have do, and do so from within that particular test. Try not to add things to your setup which are only used in one or two tests — you’re better off having some repetition than initialising your data set unnecessarily way too many times.
To illustrate this further — the following should be considered a bad practice:
And refactored as follows:
Set up in startup.
Parts of your test case don’t need to be re-initialised for every single test case. You can avoid unnecessary database queries by instantiating them in self.startup instead. In fact, you can apply this principle to all data which is not the subject of the individual test case, e.g. when testing Posts, try to avoid creating new users for every single test scenario — do it once during startup.
Sharing is caring — do it with modules.
Often times you’ll end up with common behaviours you’d want to test across multiple models. You can achieve modularity in no effort by using Ruby modules:
No magic, pure awesomeness. This simple trick will help you DRY-up your tests and share common test cases between different models.
Summing up — the good, the bad and the ugly.
Stay tuned for more thoughts on testing, but until then, here’s a short summary of what we believe is worth taking away from this article:
- Keep things simple — Test::Unit is good enough most of the time. Avoid choosing RSpec just because it’s in fashion at the moment.
- Keep things lightweight — only save records to the database if you absolutely have to. Doing it before every test case is bad for performance.
- Keep things flat — deeply nested contexts are ugly as they hinder readability of your test cases. Split your tests up into different files if they’re getting too long.
Silesian Ruby User Group, an organisation dedicated to promoting Ruby and Ruby on Rails in Silesia, is hosting its next meeting in Bielsko-Biała on the 17th of September 2010. The event will start at 7pm in Yacht Klub Polski Bielsko and move off to a local pub around 9pm for a networking session and a few pints of local brew. We’re very excited to be speaking there, so make sure not to miss it.
- Introduction to creating Rich Internet Applications using YUI3 and Rails 3 — Jakub Kuźma from Object Reload (that’s us!) will talk about using the newest version of Yahoo! User Interface Library to create sophisticated browser applications. - TemplateDerby — extended ERB — Błażej Kosmowski from Selleo will present his DRYML inspired templating system based on ERB - Objects in the database — Tomasz Bąk from Selleo will guide us through interesting ways to serialise objects in relational databases with ActiveRecord, YAML, JSON and others.
Whether you’re genuinely interested in any of these topics or just want to hang out with the local Rails community, SRUG meetings are definitely worth coming to. Registration is now open at srug.pl!
PS. Have you heard about the Rails 3: Appreciate with Charity campaign? We’re giving back to the community by raising money for charity: water to help build a freshwater well and give 5,000 people access to clean water. If you enjoy using Rails 3, please consider donating.
We are glad to be able to announce the line-up of tech conferences we will be attending in the next few months. You will be able to meet us at the Future of Web Apps London 2010 (4-5 Oct 2010) as well as RubyConfUa 2010 in Kiev (16-17 Oct 2010). Give us a shout if you would like to meet up and chat.
RubyConfUa and Future of Web Apps are two completely different beasts in the conference world, yet both very relevant to what we do. The former is a great opportunity to socialise with our fellow Ruby programmers, exchange knowledge and talk about all the latest and greatest inside the world of Ruby and Rails. The latter gives us a chance to reflect on web application market and get a glimpse into the future we are all helping to create. We could not recommend them highly enough.
At RubyConfUa we are particularly looking forward to hearing our friend José Valim talk about Past, Present and Future of Rails. We are also stoked to hear Piotr Sarnacki and Hubert Łępicki give their talks on Rails 3 mountable apps and Measuring Agile Development Process with Ruby.
At RubyConfUa you will be able to meet:
- Jakub Kuźma - Szymon Nowak - Wojciech Wnętrzak
Future of Web Apps also has a fantastic line-up this year. Kicking off with NOW is the time! by David Hauser, followed by The Future of Startups by Andrew Mason from Groupon and The 37signals way: A look into the design process of 37signals by Ryan Singer, this year’s FOWA is looking to be nothing short of excellent.
We’ve just launched our new website and now we’re updating it with a blog! This is where we’ll be posting about our insights into web development, design, business and more.
We’ve always wanted an outlet to share our thoughts with our audience and now we’ve got one.
Stay tuned for more:
- Ruby on Rails articles and tutorials - Product updates - Insights into how we do business - … and more!
