At Zorros we build online software and mobile applications to boost other businesses. Innovative web applications, business processes automation and mini ERP’s, web shops, easy-to-use online reporting tools on top of old and ugly systems (SAP for example), mobile apps for large companies. Our technology of choice is Ruby on Rails and iOS/Android.

Currently we are looking for an iOS developer that can join us for a 3 – 6 month project (likely to be renewed) to join our 7-headed team and help us realize some exiting projects. What profile are we looking for?

• You fit in our company spirit: we believe in open communication with lots of autonomy and responsibility for the individuals in our team. You love your job and you are passionate about it, you are driven and motivated, you hunt successes. We do not believe in work-for-work, useless tasks and average quality. We have a very flat and horizontal company culture, there are no “bosses” and “employees”.
• You are not happy when our client is not happy.
• You write maintainable, good, stable, tested quality code. We don’t accept dirty code!
• You work from home and show the necessary responsibility.
• You have a lot of freedom, so you can deal with a lot of freedom as well & behave proactive.
• You are pragmatic. You won’t loose too much time on irrelevant details.
• You believe in our company values: solving problems, driven by passion, no-nonsense, simplicity, quality.
• You are communicative and can collaborate with developers and project managers.
• You speak and write English.
• You have full time focus on Zorros. We don’t want your attention spread, we want you to work solely on Zorros projects. The subconscious mind works best when it is focused on one task. We want this to be your sole focus for that reason.
• To challenge us, tell us if we are an idiot if we are being one. In other words, don’t blindly listen to us. We are not your boss, we are partners.
• You must have a track record for completing projects. Working them through to completion. Too many developers just go 80%. You must be a 100%’er or we can’t work together.
• You must be a problem solver. Don’t come to me with problems, come to me with a problem and then the potential solutions for the problem. Then – we can brainstorm and pick one of the solutions. I don’t expect you to know solutions to problems, I expect you to consult forums and use google to find solutions to problems on your own. I want a driver, not someone I have to babysit.
• To understand Rapid Application Development. Release early, release often, get feedback, and make progress.
• To be interested in the success of this project after version 1.0. Version 1.0 will just be the beginning and I’ll need your help after we release the first version.
• To release features on time. (You set time frames, not me, so this shouldn’t be a challenge).
• When releasing a feature, bug test it yourself before showing me. Don’t show me a feature you have not tested once. I will go through all features to double check them, but I am not your initial bug tester.
• Accurate time quotes on development time frames. You do not have to be 100% accurate. But do not tell me a time frame you think will make me happy. Tell me a time frame that you can complete the bug tested work in.

Do you recognize yourself in this description? Any questions about this vacancy?

Please get in touch with us via pieter[@]zorros.be!

At Zorros we build online software and mobile applications to boost other businesses. Innovative web applications, business processes automation and mini ERP’s, web shops, easy-to-use online reporting tools on top of old and ugly systems (SAP for example), mobile apps for large companies. Our technology of choice is Ruby on Rails and iOS/Android.

Currently we are looking for two RoR developers that can join us for a 6 month project (likely to be renewed) to join our 7-headed team and help us realize some exiting projects. What profile are we looking for?

• You fit in our company spirit: we believe in open communication with lots of autonomy and responsibility for the individuals in our team. You love your job and you are passionate about it, you are driven and motivated, you hunt successes. We do not believe in work-for-work, useless tasks and average quality. We have a very flat and horizontal company culture, there are no “bosses” and “employees”.
• You are not happy when our client is not happy.
• You write maintainable, good, stable, tested quality code. We don’t accept dirty code!
• You work from home and show the necessary responsibility.
• You have a lot of freedom, so you can deal with a lot of freedom as well & behave proactive.
• You are pragmatic. You won’t loose too much time on irrelevant details.
• You believe in our company values: solving problems, driven by passion, no-nonsense, simplicity, quality.
• You are communicative and can collaborate with developers and project managers.
• You speak and write English.
• You know what Ruby on Rails, HTML, CSS, Javascript, cucumber, rspec, git, github, TDD, MVC, fat models, capistrano, deploy, commit and branch are. The typical stuff.
• You have full time focus on Zorros. We don’t want your attention spread, we want you to work solely on Zorros projects. The subconscious mind works best when it is focused on one task. We want this to be your sole focus for that reason.
• To challenge us, tell us if we are an idiot if we are being one. In other words, don’t blindly listen to us. We are not your boss, we are partners.
• You must have a track record for completing projects. Working them through to completion. Too many developers just go 80%. You must be a 100%’er or we can’t work together.
• You must be a problem solver. Don’t come to me with problems, come to me with a problem and then the potential solutions for the problem. Then – we can brainstorm and pick one of the solutions. I don’t expect you to know solutions to problems, I expect you to consult forums and use google to find solutions to problems on your own. I want a driver, not someone I have to babysit.
• To understand Rapid Application Development. Release early, release often, get feedback, and make progress.
• Can hack together HTML and CSS if needed. A UI will be provided, but if we need to add something on the fly or make a tweak, any skills here would be a bonus.
• Proficient with the command line interface. Must understand basic system administration. Capable of launching and administering RoR apps.
• To be interested in the success of this project after version 1.0. Version 1.0 will just be the beginning and I’ll need your help after we release the first version.
• To release features on time. (You set time frames, not me, so this shouldn’t be a challenge).
• When releasing a feature, bug test it yourself before showing me. Don’t show me a feature you have not tested once. I will go through all features to double check them, but I am not your initial bug tester.
• Accurate time quotes on development time frames. You do not have to be 100% accurate. But do not tell me a time frame you think will make me happy. Tell me a time frame that you can complete the bug tested work in.

Do you recognize yourself in this description? Any questions about this vacancy?

Please get in touch with us via pieter[@]zorros.be!

I am a huge fan of simplicity. Cut, remove, strip down. Keep the essence. Everywhere I can.

I’m happier with less stuff. Less stuff to manage, less things to take care of or to worry about. I recently did sell all my CD’s, since I can listen any song online, anytime. At Zorros, we all work from home. Why complicate our life with an office that needs rent, cleaning, a fridge, furniture, a contract and toilet paper, and that would require me to travel back and forward every day with a car (that needs also maintenance etc…)?

KISS: keep it simple and stupid.

Also in your code. KISS your code.

At Zorros it is a rule to keep our code clean and simple. Clean and simple code has a direct business (money!) impact. Any other developer in this world that takes over your project, should be able to understand your code and start working on it, without days and days of digging into spaghetti code. “Any other developer” means also “you in 1 year from now”. What might seem the cheapest solution on short term (leave the code dirty) might become very expensive in the long term.

Orders that are lost in your webshop,  due to a failure in business logic, due to a misunderstanding of the legacy code, due to over complex code, due to laziness of the original developer, is a bad thing.

Don’t add things to the code that are not needed. Pieces of code that are added “in case we ever need this” are, in general, a very bad idea. Since most of the time, you’ll never need your special feature. Comments in the code that wrong, outdated, or saying nothing, should be removed or corrected. We try to write the less possible comments. Only comment code if it really servers for something.

The more stuff you add, the more places where it can go wrong. Only add what you really really really need at this moment to be operational. Do you want to sell waffles on the streets of New York? Then the bare minimum you need is a van, and waffles. Don’t add the 1001 possible things that might be needed for your business to operate.

The same for your code and architecture. Don’t add what is not a must right now. A CDN? Load balancing for your server? Optimized queries so they can hit billions of DB records under 1 second? Ajax? Think twice before adding any of these. Once they are added, they become a possible point of failure. They need maintenance. They need extra attention. They need you and your time. Forever. As long as this software is up and running, every now and then they will ask more of your attention than it could have been without them.

See the above bike? It looks awsome! It has a great shine over it. A fancy seat. It glitters. Except…it won’t ride. The creators of this bike have been paying too much attention on the shiny fancy glitter, and not enough on “making it ride”. They tried to be cool but forgot to make it ride. They wanted to be fancy before being effective. Result is a huge waste of time and money.

Every project has a budget and a deadline, and one of the difficulties when working with enthusiastic people on a project, is to stay within the budget and time. Enthusiastic developers or clients always have the ambition to make things perfect and focus from the very beginning on the little details. Paying attention on details is a good thing…but not too early in the process. A good approach is to focus on the core functionalities first and finetuning later.

We work in phases and iterations.

1. During a web or mobile software project, the very first deploy would contain a very very basic and even premature version of the core functionalities. No single screen is looking nice, no single screen is optimized to work fast…but the essence of the business logic is in place. When I click that button, some calculations are made. When I follow that link, some information is shown. It’s not shown in a nice way, but it is shown. At this stage, maybe 50% of the whole scope is implemented in a very basic way.
2. During the second deployment, we would strive for a 100% implementation of the whole scope, but again in a very basic way. No layout polishing, copy is still wrong, no colors, performance might be low. But now, since 100% of the business logic is implemented, the client / user can get a first feeling on how the app really works. Clients have something in their mind (often written in Functional Designs or Specs), but once they see the app really working, playing with the app, new reflections come up. Things do not look so good as they did look in the Functional Design. The business logic and calculations seem to have some missing logic. It’s now time to start iterating on the business logic.
3. Iterate on the business logic (still not paying attention to the look and feel / polishing)
4. Iterate on the business logic
5. Iterate on the business logic and basic UI
6. Iterate on the business logic and basic UI
7. …
8. …
9. Business logic is OK by now. Let’s start iterating on the design, look and feel, speed and so on. Now it’s the time to start polishing. Not before. In the first versions, a shadow or a rounded box DO NOT MATTER AT ALL. Try to nail the business logic first before optimizing all the rest.

Note: this is especially true for web and mobile software. If the main purpose of your web app (or site) is to be super overwhelming sexy, but you have no business logic in it, then you should start focussing on design much sooner.

We kindly ask all developers at Zorros to read business and UI books. Not to annoy them. But to avoid we are a bunch of  tech-only-tunnel-vision guys. Do you know the tech-only-tunnel-vision guy? He’ll go for the best technical solution. The most compact code. The holy single responsibility principle applied everywhere. No single page without AJAX. Everything is HTML5 and CSS3. A super scalable server. The perfect test suite.

And those are all great principles. But here is the thing…

If you ONLY focus on those principles, you’ll never build great software. You’ll build an un-userfriendly and worthless piece of “perfect code”. And what is that used for? The tech-only-tunnel-vision guy is the guy that over-cares about technical setup, but forgets 2 things:

1 – They forget that people will be inter-acting with this application.

You can make software that is 100% meeting the business logic, but completely unusable to work with. I’m not talking about design here. I’m talking about UI. User interaction. UI is crucial and a must. Design is a nice to have and a matter of taste.

If buttons are called “destroy” in stead of “remove this comment“, if all text is shown in the same size so no text is given more importance, if there is no white space between elements and everything is just thrown in the page, if the fields of a form are in random order in stead of a logic order, if some fields are automatically saved without informing the user that anything was really saved in the backend, then we have UI problems.

UI is a matter of caring. Care about your end users. Think how they will think. You don’t have to be a top designer to care a little about your users. You just have to put yourself in their shoes, look at each screen, and try to think how they will think. 90% of the UI work can be done by anyone. It’s the low hanging fruit. Changing the text ”destroy” with “remove this comment”. You don’t have to be a designer for that. You just have to care about about your users. When you finish an application that you have been working on for weeks or months, the least you could do is look a few hours at the main screens, and rephrase some text, reposition some buttons, color the delete buttons in red, etc… Again, 90% of the UI care can be done by anyone and in little time.

The tech-only-tunnel-vision guy builds screens for robots. The good developer builds screens for humans.

2 – They forget this application will eventually solve a problem

While writing an application, do you know what it is built for? Do you realize what problem you solve? Do you know the context, place, time or environment your end uses will be in while using this software? If not, you can not build good software.

Good software helps people. It takes a burden from their shoulders. It solves a problem. Now, if you don’t know what problem this software is ment to solve…how can you possibly solve it? Always think about the value your software adds, and try to focus on value addition with every single line of code you write. If a line of code does not add value to the end user, remove it. Don’t add features that are cool to work on for a developer, add features that are a must for your end users. There are tons of features shipped to a production server that are used 1% of the time. A pitty.

Zorros, that’s a team of 7 people for now. Two of which live in Belgium, five in Spain. Every one of us works at home. When we say that to others they say ‘great!‘, but at the same time you see them think ‘how the hell does that work?‘. Well, it has been working very smooth so far.

We build web based software. In order to build and deliver this software for our clients we only need an internet connection and a lot of passion. Of course we often meet physically with our customers in order to stay aligned. But for the realization of our service there are no requirements at all to physically be together. “Being physically together at work” dates from the times people had to physically assemble cars in a factory.

Moreover, we work together very efficiently. This is all about conventions, discipline, motivation and good collaboration tools. By having good discipline on how to use our collaboration tools, our team has become a well functioning machine. We structure, maintain, and assign our to do’s in our project management tool Basecamp very strictly. We log our time regularly in Freshbooks, etc.

Working like this, we have instant access to the status of all our projects: remaining to-do’s, functionality to be tested, budget spent, etc. Everything is available within a second, 24/7. This means we don’t need time consuming status meetings, discussions about remaining work, or any other waste. Less waste means more productive time. Moreover, because we are not physically together, those web tools are the only way to keep track of everything. Because people can not fall back on “meetings”, there is a huge tendency to keep all data very up to date.

On top of that, everyone can wear the clothes he likes, organize his day as suits best, burp after lunch, feel like home at work. No needless alignment on every silly detail. No over-brainstorming and needless meetings. If we need to talk, we open Skype and talk. But since there is a certain “barrier” to start talking (you have to actually disturb someone on Skype), it obliges all of us to double think. Do we really need to talk? Do I really need to disturb 5 other people just to ask their opinion about the color of a button, or can I just decide this on my own and go on? We think that there is too much small talk. Too much brainstorming. Too much meetings.

Imagine you could work for 8 hours in a row, without any single interruption, on something you like a lot. How many people working at normal offices would dream of that? Lots. Well, at Zorros, we all work from home, without distractions, with our favo piece of music, cup of coffee and piece of fruit next to us, on things we like.

At Zorros we like SaaS products. We use them for our business administration (eg. Freshbooks and Basecamp), and we build them for our customers. Now we’ve come up with a new product ourselves, our Mobileloggr.

What?

Mobileloggr offers little functionality, with high added value. A simple tool to integrate mobile time tracking with existing enterprise softwares like SAP, Microsoft, Oracle, Sage, etc. Employees or subcontractors log time via their mobile device. These logs are made available to any enterprise software, via API. The logs can then be used for reporting, cost calculation, etc. This is the strength: no limitations on how the logs are used. Simple functionality, with high added value.

Why?

Service or installation companies often suffer with this issue. “How many time has been worked on each taks, project or client?”. With the Mobileloggr it’s easy to make this information available.

Moreover, many companies don’t know how many time is spent on which tasks. How is it possible to monitor performance without tracking the exact time that has been worked on each activity? Without this information it is impossible to analyse productivity, performance, workload, etc.

Different?

How is this different from all other mobile time tracking tools out there? It’s different because we treat it as an add-on for enterprise software (ERP systems), not as a standalone solution. We allow businesses to track time and consume the logs for further processing, nothing more. More than the time tracking functionality, the focus lies on integration with other business softwares like SAP, Microsoft, Oracle, etc.

De trends van web based software en mobile software openen heel wat nieuwe mogelijkheden voor bedrijven.  Smartphones maken de gemeenschap bijzonder mobiel wat bedrijven bv toelaat de klantenrelaties te beheren via apps of te evolueren richting een efficiëntere organisatie. Vele van deze applicaties zijn bovendien beschikbaar in SaaS vorm.

Een studie van Aberdeen wees uit dat bedrijven die gebruik maken van Mobile Business Intelligence er in slagen om kritische management beslissingen te nemen in één zesde van de tijd die bedrijven zonder dergelijke tools nodig hebben. Door de BI infrastructuur uit te breiden naar mobiele devices zijn bedrijven in staat veel sneller in te spelen op wijzigingen gerelateerd aan de markt, klantnoden, interne verschuivingen, etc.

Een steeds groter aandeel van bestaande en potentiële klanten van bedrijven heeft vrijwel continu toegang tot mobile apps. Deze verwachten dan ook te kunnen interageren met deze bedrijven, wanneer ze dat willen. Het beheer van klantrelaties krijgt aldus een nieuwe dimensie. Klanten willen ook meer en meer overgaan tot transacties (aankopen) via mobiele devices. Het klassieke face-to-face model om klanten te overtuigen over te gaan tot de aankoop van goederen wordt, in heel wat B2C segmenten, snel ontoereikend om competitief te blijven. Net zoals een goede website intussen noodzakelijk is om geloofwaardig over te komen, wordt het in de toekomst  noodzakelijk één of meerde goed werkende apps te hebben. Zo kunnen bestaande klanten fans worden die nieuwe klanten aanbrengen.

Mobile apps kunnen bedrijven ook toelaten om meer omzet te genereren. Vaak bezitten bedrijven over heel wat informatie die toegevoegde waarde kunnen betekenen voor klanten. Vooral in de dienstensector kunnen hier mogelijkheden liggen, om intern opgebouwde kennis en informatie via apps aan te bieden. Dit kan een manier zijn om extra markten te veroveren en dus hogere omzetten te realiseren.

Mobiele applicaties kunnen bedrijven ook helpen bij het realiseren van een efficiëntere bedrijfsvoering. Mensen moeten niet steeds terug naar hun bureau en PC om bepaalde gegevens in te geven of op te zoeken. En als je bekijkt welke activiteiten zich ‘op afstand’ (dwz niet aan een bureau met PC) afspelen in vele organisaties, dan is dat vaak niet mis: verkoopgesprekken, marketingactiviteiten, installatie van producten, onderhoudsactiviteiten, productie-en voorraad activiteiten, etc. Het zijn allemaal activiteiten waarvan de administratieve verwerking eenvoudig en efficiënter zouden kunnen met behulp van mobiele technologie.

De opgang van mobiele software biedt ongeziene mogelijkheden om waarde te creëren voor klanten, en interne kosten te reduceren. In plaats van het te beschouwen als een technisch snufje, zouden bedrijven mobiele software dus moeten aanwenden als een strategisch middel om de bedrijfsresultaten te verbeteren.

At Zorros we build online software and mobile applications to boost other businesses. Innovative web applications, business processes automation and mini ERP’s, web shops, easy-to-use online reporting tools on top of old and ugly systems (SAP for example), mobile apps for large companies. We love it all. Our technology of choice is Ruby on Rails and iOS/Android.

Currently we are looking for a UI / web designer to join our 5-headed team and help us realize our new projects. What profile are we looking for?

• You fit in our company spirit: we believe in open communication with lots of autonomy and responsibility for the individuals in our team. You love your job and you are passionate about it, you are driven and motivated, you hunt successes. We do not believe in work-for-work, useless tasks and average quality. We have a very flat and horizontal company culture, there are no “bosses” and “employees”.
• You have a strong interest and feeling for web and software design and UI, and you have experience in the field. You know the most important design patterns, and you follow UI and design trends. Ugly software without usability is no software.
• You are not happy when our client is not happy.
• You can work from home and show the necessary responsibility.
• You are pragmatic.
• You believe in our company values: solving problems, driven by passion, no-nonsense, simplicity, quality.
• You are communicative and can collaborate with developers and project managers.
• You speak English.
• You know what Ruby on Rails, HTML, CSS and Javascript are.

Do you recognize yourself in this description? Please get in touch with us via jeroen[@]zorros.be!

We hebben reeds besproken hoe een software implementatie dient te vertrekken van de (TO BE) bedrijfsprocessen over de verschillende afdelingen heen, in plaats van de huidige manier van werken te ondersteunen. De software zal dan de bestaande inefficiënties beter wegwerken. De eerste stap is dus het  beschrijven van de TO BE situatie. “Wat zou de optimale manier van werken zijn, hoe kunnen we huidige inefficiënties wegwerken?” Pas in een volgende fase dient gekeken te worden naar hoe software dit kan ondersteunen.

Hoe pakken we die eerste stap – een kritische analyse van de bedrijfsprocessen – nu best aan? Eigenlijk komt dit neer op het beantwoorden van de vraag: “Wat zijn de noodzakelijke stappen voor het realiseren van toegevoegde waarde, namelijk een product of dienst waar onze klant bereid is voor te betalen?” Alle stappen die geen waarde toevoegen, maw waarvoor de klant niet betaalt, én niet noodzakelijk zijn moeten we dan proberen elimineren. Dit is wat men de term ‘lean management’ heeft meegegeven, maar komt eigenlijk neer op gezond boerenverstand.

Een handige leidraad om van te vertrekken is het Order To Cash proces. Dit is de aaneenschakeling van alle activiteiten van orderontvangst tot en met betaling door de klant. Typisch bevat dit volgende onderdelen: orderontvangst, planning (afchecken van behoeften met capaciteit), productie en/of aankoop, levering, facturatie, betaling. Je kan deze activiteitenreeks modelleren via modelleringtechnieken (bv BPMN), om zo een flowchart te bekomen. Vaak echter, volstaat een eenvoudig Word document (aangereikt met enkele schema’s), waarin de verschillende stappen beschreven worden die noodzakelijk zijn voor het realiseren van toegevoegde waarde voor de klant.

Het blijft verbazen hoeveel inefficiënties op die manier aan het licht komen. Tenminste, als de betrokken medewerkers er in slagen los te komen van de bestaande gewoonten en systemen, en durven open te staan voor dergelijke denkoefening. Eens we deze TO BE processen op papier staan hebben, is het zaak van deze processen in voege te krijgen. Om dit te realiseren zijn 2 zaken essentieel: 1) Eventuele noodzakelijke aanpassingen in de organisatiestructuur, en 2) Software die deze TO BE processen passend ondersteunt.

Tot slot nog een aantal concrete voorbeelden van mogelijke inefficiënties:

1. Linken offertes – orders – facturen: vaak zijn dit gescheiden documenten. Wanneer een offerte goedgekeurd wordt, moet manueel een order aangemaakt worden. Eens het order uitgevoerd is, moet manueel een factuur opgemaakt worden. Deze drie documenten bevatten voor 90% dezelfde gegevens (klantgegevens, en artikel/dienst gegevens). In een goedwerkend systeem moet deze informatie slechts 1 maal ingevoerd worden (in dit geval in de offerte), en worden de daaropvolgende documenten automatisch aangemaakt met een druk op de knop, waarop ze eventueel verder aangevuld worden.
2. Automatische behoeftebepaling: langs de ene kant hebben we de klantorders die binnenkomen (of projecten), en langs de andere kant hebben we voorraad die gebruikt wordt om, eventueel na bewerking, deze klantorders te realiseren. Heel vaak komen de behoeften bij de magazijnier terecht, die dan controleert welke artikelen uit voorraad dreigen te lopen, en een lijstje maakt van wat moet bijbesteld worden. Dit lijstje wordt dan doorgegeven aan de aankoper die de aankoopbehoeften zal bundellen in bestellingen. Ook in bedrijven waar reeds software pakketten aanwezig zijn, is dergelijke werking geen uitzondering. Het vergelijken van de klantbehoeften tegenover de beschikbare voorraad, en het (op basis van bestelpunt per artikel) lanceren van aankoopvoorstellen is iets wat heel wat tijd kan besparen.
3. Administratie aankoopfacturen: een heel tijdsrovende activiteit in heel wat branches, is het controleren van de aankoopfacturen. Klopt het bedrag op de factuur? Hadden we hiervoor niet ooit al een factuur gehad? En hebben we dit al dan niet betaald? Ook hier kan door enkele logische zaken het leven heel wat eenvoudiger gemaakt. Bv per bestelbon/bestelregel in het systeem bijhouden: ‘zoveel geleverd’, ‘zoveel gefactureerd’, en ‘zoveel betaald’. Dit lijkt zeer eenvoudig, maar wordt zelden op een logische en eenvoudige manier toegepast. Een alternatief voor grotere organisaties die grote volumes afnemen bij eenzelfde leverancier, is ‘self-billing’. Als afnemer maak je zelf de aankoopfacturen op (en stuur je ze uiteraard ook op naar de leverancier, ter controle). Dit maakt dat administratie rond ‘controle van aankoopfacturen’ verdwijnt.  Dit moet wel geïmplementeerd worden, maar in een systeem waar reeds bestelbonnen zitten is de stap naar het generen van aankoopfacturen op basis van die bestelbonnen niet zo heel groot.