Category: Management

Managing Costs of a Software Project

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

Developing software is an extremely time consuming process, requiring long hours of uninterrupted focus on the technical task at hand. That coupled with constantly learning new technologies, analysing requirements, designing, documenting,  coding, debugging, testing, installing etc. makes software development a stressful and difficult job. But no matter how difficult the job, for certain types of people the process of imagining something and bringing it to life from nothing proves to be work that is incredibly rewarding and self satisfying. Most successful software developers that I’ve met over the years love coding and most cannot imagine doing anything else with their lives.

Before I started working as a software developer professionally, I  remember spending hours sitting at my computer for hours on end writing code just for fun, without any interruptions or any other worries. When I was done my code had no bugs whatsoever and by that measure the code was perfect. If I wanted to implement another feature, I would just start coding it right away. The only limits were my own imagination. However, after I started working as a software consultant for a few years I noticed a few things that would kill the joy of coding. It’s for these reasons that many developers end up changing careers or at the very best keep switching between jobs in the hope of finding a light at the end of tunnel i.e. bringing joy back into coding.

The truth is that if you want to enjoy your career in the real world, you cannot continue sticking your head in the sand and pretend that you’re just a coding geek, and ignore the business aspects. You may not enjoy getting involved in the business aspects of software, but as the saying goes, “if you can’t beat them, join them” and believe me when I tell you that you definitely cannot beat the business people for the simply reason that they are pragmatic realists while most coding geeks are idealists with their heads in the cloud … or sand or whatever else geeky developers put their heads in. As George Carlin once said “Inside every cynical person is a disappointed idealist.” Continuing on a path of avoiding business meetings will turn you into a disappointed and grumpy pessimist, ending up complaining to your grandkids over Christmas dinner about how unfair the world is. So you may as well join the business people and turn yourself into a pragmatic realist that somehow always seems to find a solution where others see only problems.

Here’s some advise for getting involved in the business side of things. It all starts with managing ongoing costs of projects. Firstly, every software project has three components that need to be managed and there isn’t a single business meeting in which these components are not brought up:

  • Money: in the real world, people need to put food on the table, bills need to be paid and companies need to make a profit otherwise they go out of business. For this reason every little thing needs to have a monetary value assigned to it. So if you have an idea for a feature you’d like to develop, you cannot just start coding it because someone needs to pay for your time and effort. Your customer/boss will only pay for you to do it if it provides an ROI (Return On Investment) to the company i.e. a financial benefit the company gets from having this feature/application developed. Therefore before you start coding, you first have to create a proposal, estimate costs, prepare an ROI analysis, present it to the customer and wait for approval. Depending on the costs, complexity of the project and other factors this process could take a week, a month, a year, or it might never get approved (probably because your proposal sucked).
  • Time: regardless of whether you’re billing by the hour or you’re getting paid a flat salary, your time is being paid for. Therefore any feature or app you are developing must have a time constraint assigned to it because time equals money. To make matters worse, there are deadlines imposed by the customer because they need it by a certain date. If that’s not bad enough, you’re competing with other software companies, and so in order to win a contract, you’ll then have your salesman promising the customer (on your behalf) that you will in fact delivery the finished software in half the time for a fraction of the money that other companies are offering it for. While you’re still standing there dealing with the shock and horror of the situation, the salesman will then turn around and spew out motivational quotes to you which he heard at some sales seminar that he went to last week … or maybe he’ll just quote Barack Obama by saying “Yes, we can!”.
  • People: the more people are involved in a project the more politics you can expect. That’s just a fact of life. The reason being that different types of people have different agendas with different incentives in their job. So once again, before you get to write any code, people need to agree on what this code needs to do and how it needs to do it, how long it’s going to take, what budget is going to be allocated to the project and who is going to handle which work. Going forward you can expect millions of emails, phone calls, conference calls and endless recurring meetings that will make want to pull your hair out … assuming you have any hair left to pull out. Throughout this process both functional and technical specifications need to be written up which essentially serve as contracts for what will be delivered as the finished software to the customer.

You would think that people would be aware of all the above, but most people, especially inexperienced or non-technical stakeholders, somehow still believe that software projects are purely about just writing code. They either fail to foresee all the above mentioned factors or they simply choose to stick their heads in the sand and not learn from past mistakes. So they typically end up quoting purely for the time required to write the code, thereby setting up unrealistic expectations with the customers. On the customers’ end, it goes without saying that most customers are not software people and therefore never expect to pay for anything other than the time required to write code.

When these naive people inevitably run into these problems they throw their toys out the cot, arguments ensue which lead to meltdowns and they just generally become stressed out and unhappy with life. Many of the software companies then end up going out of business because of failed projects or loss of money due to time that was never billed for.

In order to to survive in this industry and avoid projects going pear shaped, you have to start managing expectations. Expectations translate into managing money, time and people and it all starts with the first quote to the customer. A million questions will arise when doing the first quote on a project. Here are some examples:

  • “Should we quote for emails, phone calls, meetings and other project management related work?”
  • “What if the customer refuses to pay for anything other than purely coding time?”
  • “Should we then just act like a charity and give that work away for free?”
  • “What percentage of the project do we spend doing project management versus time spent developing software?”
  • “What if unexpected things go wrong and the costs go up?”
  • “What if the customer keeps changing their requirements resulting in scope creep?”
  • “Should we then quote for requirements analysis and documentation work?”
  • “Will our competitors be cheaper than us because they’re not quoting for all the above?”
  • “What if our competitors undercut us by deliberately underestimating the time and effort required and oversimplifying the customers’ requirements?” This happens on a regular basis by the way. Many sales people do this because they know that once they get started on a project the customer will not be able to simply turn back if the project ends up costing more than what was originally quoted for. This approach is like the drug dealer sales approach i.e. the first one’s free, after that we’ll nail you.
  • “If that happens, will the customer be experienced enough to realise that they’re being played by our competitors and that in the long term it will eventually cost them more than they bargained for?”
  • “Should we then preempt the competitors’ tactics and deliberately under quote just so we can get the deal i.e. should we stoop to our competitors’ level?”

These are all difficult and valid questions to ask yourself before quoting on a project. What I can tell you though, beyond a shadow of a doubt, is that if you’re only charging for purely coding time, your company will inevitable go out of business. The reason being that in my experience at least 50% of the work required on most projects excludes coding time.

So what is the best way to quote and bill then?

  • Wrong sales approach: Under quote and over bill i.e. the drug dealer sales approach. As mentioned above, most inexperienced sales people will under quote and over bill in this manner and most inexperienced customers will accept these quotes, which unfortunately perpetuates these bad practices i.e. people learning from bad examples. This approach is equivalent to over promising and under delivering in terms of costing. There are all sorts of other problems which this approach can create:
    • By quoting for purely coding work and/or cutting the budget, you are cutting the time on the project, thereby putting unnecessary pressure on the developers who will end up taking shortcuts in their code, resulting in massive amounts of technical dept being accrued. In the long run, the project will end up costing way more anyway. Hence I say that you would be putting yourself and/or other developers under unnecessary pressure.
    • It goes without saying that taking shortcuts leads to lower quality code being produced and the software being filled with bugs.
    • Due to the low quality code and over-budget costs, your reputation will end up being tarnished in process. So even if you end up finishing the project successfully, that very same customer will most likely never call you again for the next project.
    • In the end it really comes down to the customer getting what they pay for. That being the reason for many internal and enterprise products only being as good as they need to be i.e. sales people undercutting competitors, underestimating requirements and customers being cheap and shortsighted.
  • Right sales approach: Over quote and under bill: it’s always difficult to estimate the costs and timelines of a project. For this reason and all the reasons mentioned above, I have found the best strategy to be as follows:
    • Sales meetings: During your first sales meeting/s with the customer, get a sense of the their requirements. You don’t need to get into too many details about every custom single business rule and how exactly each feature will be developed. The reason being that the customer is not paying for these sales meetings. Hence you don’t want to spend too much time doing the analysis and design work before any payments have been made or approvals have been granted i.e. you do not want to work for free. Furthermore, it can often happen that you’ll go through a long and rigorous analysis phase, designing and fully documenting a proposed solution only later to find out that the customer took your design to a competitor and ended up paying them for only their coding time. You may or may not be surprised to know that this in fact happens quite often. If you do this enough times your company will end up going out of business. The purpose of the sales meetings should only be to:
      • Sales Pitch: Pitch yours and the company’s services to the customer. The main aim of your first sales meeting should simply be to prove your competence and skills to the customer.
      • Requirements Overview: get an overview of their requirements for the software they’re looking to develop. Don’t get bogged down into specifics. The specifics should be left up to the analysis phase when the customer is actually paying for your time.
      • Proposal: put together a proposal for the solution you plan on implementing. This proposal should not be a functional and especially not a technical specification. There should be no mention of specific features or technical details of how the software will be developed.
        • Technical Information: from a technical perspective it should only provide an overview of the technologies (hardware, frameworks, SDKs and programming languages) you plan on utilising to provide the solution. You can  provide them with generic architecture diagrams, but don’t spend too much time creating custom diagrams that are specific to their business.
        • Solution Benefits: you should mention the benefits of implementing such a solution. This could be an increase in productivity, accuracy, automation etc.
        • Costing: this is the tough part that most people get wrong. Only through experience will it become easier to prepare costing estimates.
          • Development Costs: firstly, you need to think of the time required to develop the software by breaking down the tasks. If you’re using XP and Agile, these could be your stories or whatever you like to call them. If you’ve done similar projects in the past it will be easy to make an estimate. However for features that you’ve never implemented before, I would advise you to always be conservative i.e. think about the time required for research, testing debugging etc. If you’re not the one developing the software, this process will be become even more difficult in which case you will need to speak to the developers and get estimates from them.
            • Developer Confidence: Keep in mind that you cannot just take the developers’ estimates at face value. The reason being that some developers provide optimistic estimates, while others provide pessimistic estimates and this is based on their confidence, which may or may not necessarily have anything to do with their actual skill level. Confident developers typically tend to under estimate the time and effort required for coding, while under confident developers will overestimate time and effort.
            • Code Sloppiness: Some developers can be incredible quick to write code but they code can be sloppy. For such developers, you need to add buffer time for them to go back to refactor and debug etc. Others are perfectionists and take really long to code, but when their work is done it’s actually done. Therefore, you need to take all of this into account on the overall costing.
            • Buffer Time: Once you’ve come up with a fair estimate, it is best to always add a further buffer by multiplying the estimated hours with a factor. This factor is something of gut feeling you get through experience. For example, suppose a developer gives you an estimate of 10 days of development, you could then multiply that by 1.5, thereby your estimate to the customer being 15 days. The reason for this buffer is to take into account unexpected issues that can and do always pop up. Some may say that allocating extra time encourages procrastination, but I think that’s non-sense because it is the project manager’s job to check on up progress and ensure that people are meeting their timelines.
            • Do not quote on details: when quoting for development work, do not make the mistake of separating and displaying costs for every little coding task e.g. do not quote for each and every single button that they want on a form. Instead group the costs together and have only one or two development line items on the quote. The reasoning behind this is because you do not want the customer interrogating you about every single line item e.g. “Why would it take 8 hours to develop a single button.” The purpose of not quoting on details is not to be dishonest about the costs, but rather to avoid having technical debates with a customer that isn’t technical i.e. the customer has no idea how much work goes behind implementing the logic of that specific button and therefore to the customer it just looks like a simple button, while there could be 2000 lines of code behind that button for it to do what it’s supposed to do.
          • Project Management Costs: think about all the time that will be spent on the phone, writing emails, in meetings and driving around to those meetings. You must also take into account the kind of people the customers are when making this estimate. If your customers are professionals that know exactly what they want and they themselves plan ahead, then the project management costs can be reduced. However, you will have customers that know very little about software projects, are unprofessional, will constantly change their minds about what they want and the goal posts and timelines will constantly change. For unprofessional customers, I’d advise you to increase the project management costs substantially because you’re going to be doing a lot of baby sitting.
          • Analysis Costs: this is the time required for you to sit in workshops and meetings to discuss and finalise requirements and write up documentation. This time needs to be paid for because at least a third of your project will involve analysis work. It is for this reason that you should never make the mistake of starting the analysis phase before presenting the proposal and getting the customer’s go-ahead on the project.
        • ROI Analysis: finally once you’ve come up with a final number for the costing of a project, you then need to sell it against a value you’re providing to the customer’s business i.e. you need to give your customer a financial reason to spend the money on doing the project. Simply listing reasons is not going to cut it. Your motivation for doing the project needs to be have financials attached to it and that is typically the ROI (Return On Investment) calculation. In most cases, customers will already know why they want the software implemented, that being the reason why they called you in to take on the project. However, that may not always be the case, especially in cases when you are the one approaching them. In such cases you need to show the customer that doing the project will be an investment in their business and like any investment it must have a return/payback in a certain amount of time. So for example, if the project costs will be $100 000, you need to show the customer that the software will reduce costs in other areas of their business thereby enabling them to save X amount of money every month.  Those savings will amount to the total investment in a certain amount of time and that will be your final ROI payback period. Going forward the customer will continue to save for as long as they continue using your solution. In other words, the purpose of an ROI calculation is to establish a win-win deal with the customer whereby you earn money from the project implementation and the customer wins even more in savings over time. Selling based on ROI is the most difficult kind of sale you can make because you will need to have a thorough understanding of the customer’s business in order to put together an ROI calculation. However this kind of sale is also the most rewarding because instead of selling based on billable hours, you’re selling based on the value your software solution provides. It always helps if you are already familiar with the specific industry that the customer is in. If not, then you will be required to do a lot of research into the industry. Either way you will need to ask the customer a multitude of questions regarding their business before you can understand how to solve their problems and cut their costs.
      • Project inception: once you’ve presented the proposal to the customer you can expect to have a few backwards and forwards rounds of meetings and discussions about the proposal. Do not make the mistake of starting a project without the go-ahead from the customer. If it is a new customer that you’ve never dealt with in the past, I would advise you get a formal approval in written form from the customer. This can take the form of a PO (Purchase Order) or otherwise some sort of a signed contract.
      • Analysis and Specification Documents: it is only at this stage once you’ve gotten the go-ahead from the customer that you can start working. However, it is still not time to start coding just yet.
        • Project Plan: First and foremost you need to put a project plan together. The project plan will consist of the timelines of when each project deliverable (feature/work) will be completed and which resources (people) will be working on those deliverables. Both you and the customer need to agree on the project plan and the timelines need to be in line/comparable to the project costing in your proposal.
        • Functional and/or Technical Specifications: included in the project plan should be time allocated for analysis work and writing up the functional and/or technical specification. This phase of the project will involve having workshops and meetings to discuss the requirements of the software. Throughout this process, you will document the requirements in a formal specification document.  Many developers will say that documentation is a waste of time, but in the business world these documents will essentially server two purposes:
          • Contract for work required: The specifications will serve as a contract for what the customer can expect of the software. No more and no less than what is specified in the document will be delivered to the customer for the agreed upon price. It is for this reason that many software companies only quote the customer after the analysis phase, because they will say that they cannot quote for the project without fully understanding all the project requirements in detail. However, remember that I mentioned that in the costing process you should always add a buffer i.e. allocate extra budget and time for unexpected costs. This buffer that you added in your costing should cover any unexpected work that is being requested during the analysis phase and it will also protect you from doing the analysis phase at the risk of not getting paid for this work.
          • Mitigating scope creep: without a specification in place, the customer can continue asking for changes and you will end up spending way more time on the project than you initially anticipated all the while the customer is getting all this additional work for free.
      • Billing:  Many software companies bill only at the end of the project with an agreement in place that the customer only pays once the project has been completed and the solution has been implemented and tested. This is a huge mistake. The reason being that the customer will be under the impression that the project costs you presented in the proposal are a flat fee and in such a scenario the customer will not take into account the accruing costs of changing requirements, calling you in for additional meetings etc. All of that can land you in a mountain of scope creep costing your company ridiculous amounts of money. Hence it is important to:
        • Bill actual hours not estimated hours:  It is crucial to make the customer understand that the costing you did in the proposal are only estimated costs and that they will be billed the actual hours worked instead of these estimated hours. This clearly tells the customer that it will not be a flat fee for the project, but instead can change based on changes in the requirements. If you added a buffer to the budget (over estimated costs) in your proposal, the customer will end up being pleasantly surprised when the costs of the project are less than the estimated costs. However, if the customer continuously asks for changes throughout the project even after the specification document has been agreed on, these changes will be handled as CCRs (Change Control Requests) which fall outside the scope of the initial specification. The CCRs must be paid for and given enough of these CCRs the total cost of the project will end up going over the initial costing in the proposal. Having these mechanisms in place will encourage the customer to think twice before asking for changes to the initial agreement and will protect you against scope creep.
        • Bill in cycles: Bill the customer for the hours worked in continuous cycles e.g. monthly or even every two weeks. The developers and other resources on the project will then have to keep track of their hours worked and ensure that the costs are not going over budget. If the costs do end up running over budget, either because your initial estimation in the proposal was wrong or because of CCRs, the customer must be alerted of it and approval must be gotten from the customer before continuing with the project.

Keeping all of the above in mind, here’s a summary of golden rules to follow in order to manage the costs of a project.

  1. Always over quote and under bill instead of under quote and over bill.
  2. Do not get into too many details in the sales cycle i.e. when drawing up the proposal and estimating the costs of the project.
  3. Bill actual hours worked instead of estimated hours: Explain to customers that the quote is purely an estimation and that they will be billed actual hours worked rather than estimated hours. Explain to them that if there are no change requests, they can most likely expect the total cost to be less than the estimated cost in the initial proposal.
  4. Never work for free: aside from the sales meetings, proposal and costing, no other work should be done for free without formal approval from the customer. Even after the project has started, any change requests must be paid for.

Why do large software companies open-source their projects that they’ve invested so much into?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

This is a good question, because it seems like a bit of a contradiction: these companies are there to make money and they’re spending money to develop these products but they’re still “giving” their code away for “free”.

Obviously I don’t know exactly what the thought process is by the executives of these companies, but I can take a guess. My guess is that open-source is great if you want to:

  • Lower costs: get others in the open-source community to work for free in testing and spotting bugs in your software.
  • Lower risk: this goes along with lowering costs i.e. lowering the costs lowers you investment risk. Furthermore, getting feedback from the open-source community is a lot quicker than having to wait for the software to be released and only thereafter get feedback from your users, by which time they might have created a negative impression with the end-users (if the software is full of bugs).
  • Increase adoption rate: most of the products being open-sourced are SDKs and other development tools. This is very beneficial to developers using those development tools i.e. because it gives the developers more freedom and control. In the long term they end up with more developers/users hooked on their platforms at a quicker rate. As an example, I’m guessing it’s one of the reasons Microsoft opted to finally open-source .NET because it would get a lot more developers hooked on their platform, programming languages and development tools, which ultimately results in more apps being developed using Microsoft technology. Once they’ve increased the number of apps on the market developed using .NET, I’m pretty sure Microsoft have plans to capitalise on that in one way or another.

When to open-source and when not to open-source

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

If you’re a developer and have no intentions of every getting paid for writing code, then deciding between open-sourcing your software or not can be a simple decision. However, if you have any intentions to get compensated for your work, then the decision to open-source or not can be a complicated and long winded debate which has gone on for decades. On the one side you have the capitalists/conservatives that sell software for a price and their pricing models are relatively simple to understand especially in commercial and non-enterprize environments i.e. you get this product for this price. On the other hand, you have the open-source socialists/liberals/anarchists, advocating for making software “open”, transparent and most of the time offering it for free. However, for anybody that has ever delved into the open-source debate, they will quickly realise that open-source is in fact not that clear and transparent after all.

It’s all good and well to spew out socialist rhetoric about how we should all be more altruistic by volunteering our time and skills to open and transparent software communities, but once we’ve all had our turn at singing kumba-ya, the truth is that in reality there’s no such thing as free lunch. Meaning that although many open-source enthusiasts pitch the idea of so called free software, the users will still end up paying for it one way or another, be it in some sort of fee, time, energy and/or frustration. The reason being that in the real world, time equals money and money makes the world go round. Therefore, any developer working on a “free” and open-source project still needs to pay the bills, put food on the table and at the very least still have money left over to buy a laptop on which to work on. So how do open-source developers get compensated? Open-source projects typically start off as side-line hobby projects, then perhaps moving on to offering paid for versions and/or charging for services.

Over the years I’ve thought about this debate countless number of times and like most analytical people I’ve searched far and wide for an absolute answer i.e. is open-source good or bad. When I was younger I leaned more towards the open-source point of view and their anarchist/hippie rhetoric about how corporations are evil, money-grubbing establishments designed to create monopolies and control people’s lives. Now that I’ve gotten older, my view has become a bit more conservative. Maybe it’s got something to do with there being a grain of truth in Winston Churchill’s wise words where he said that “any man who is under 30, and is not a liberal, has no heart; and any man who is over 30, and is not a conservative, has no brains.”

So here’s my attempt at an absolute answer as to when to open-source and when not to:

  • How most open-source projects start off: as the saying goes, “necessity is the mother of all inventions”. By that token, most open-source projects start out from a need/problem that someone has. A developer may want to achieve something that they cannot do with commercial software that is available or they just don’t have the money to purchase commercial software that can perform the given task. While developing this new app for their own needs, it suddenly dawns on the developer that other people may have the same need/problem that their new app can solve. At this point the developer begins to think about how they could possibly get others to use this new app and possibly capitalise on it. After careful consideration they realise that there’s more to selling software than simply putting a price tag on it i.e. a company needs to be setup, marketing needs to be done, payments need to be captured, orders and invoices need to be created, taxes need to be paid and amongst many other things, all sorts of people need to be hired e.g. marketing, sales, finance, support etc. Starting and managing a company requires a lot of work and responsibility. Due to the fact that a descent amount of capital is required, it also involves a huge amount of risk i.e. it’s not always easy to predict whether or not a software product will be a hit or not. So as opposed to going through that whole nightmare, our friendly developer decides to rather just upload his code to a popular open-source repository that all his friends can access. If nothing else, it will look good on their resume.
  • If the software is a hit: if there proves to be a substantial demand for the software, the developer may begin thinking about capitalising on it. At this point the developer will probably be stuck between a rock and a hard place. If he closes down the open-source repository and begins to charge for the software he’s fear is that the users will just continue using the latest open-source version available and never purchase any new versions. Even if there are some people willing to pay for the software, the problem is that the developer will never be able to sell it to enterprise customers because no large company will agree to adopting a product that is being supported by a single individual i.e. it would just be too risky for the company. So it’s a bit of a chicken and egg scenario i.e. you need to generate revenue to hire more people, but customers are hesitant to commit to a one man show. On the other hand if he keeps the open-source repository available, then there is no way to make money on it. To get out of this dilemma, most developers in this situation either begin selling services or offering paid for upgraded versions with additional features.
  • Charging for services approach: most open-source developers will write the code for free to develop the software, but if users need any help with specific feature requests, installations, advice or any consulting services, they will be charged an hourly rate or are sold a 1/3 year Service Level Agreement. As a bit of a realist, it is at this point that I start questioning the incentives put in place for this type of revenue stream. I ask myself, what incentives do open-source developers have to produce quality software that is easy install and use when their primary revenue stream comes from selling services? If charging for services is your only revenue stream on an open-source project, then there is a clear conflict of interest in this approach and I would advise against it. Reason being that what users want is software that is easy to install, configure and use, while at the same time the developers are well aware that the easier the software is to configure and use, the less services they will sell. So what you end up with, is open-source software that is counterintuitive and users are constantly left with more questions than answers. In this kind game with these kind of incentives in place, there is not much that is open and transparent to the users i.e. the software and code is available and free for anybody to use, but nobody knows how to set it up and us it. You may be of the opinion that it doesn’t matter whether there’s a conflict of interest or not, as long as you’re making some money off of your efforts. However, my argument would be that users are not stupid, they always know when there is a conflict of interest and sooner or later they will start posing questions. This approach also creates confusion that results in users asking why you’re doing some work for free while charging for other work. This is where open-source can lack transparency. With the above said, there are some more negative side effects with this approach:
    • Minimal documentation: the whole point of writing documentation is to make it easier for users to understand the process of installing, configuring and using a given piece of software. Given the fact that many open-source software is offered for free, the developers have almost no incentives to write comprehensive documentation i.e. the more difficult it is for a user to get up and running and troubleshoot issues themselves, the more services the developers can sell. What you naturally end up with is open-source software that often has little to no documentation aside from a simple two page quick start guide. The counter argument from open-source developers is that “the code is the documentation, just look at the code”. But if we cross over from the delusional hippie world into the real world, we realise that most users are not coders and therefore having the code adds zero value to their lives. Even as a coder myself, if I’m interested in using someone else’s software I will neither have the time nor the interest in doing support on other people’s products. Personally I just want to be able to click install, use the software and move on with my life because I have enough of my own code to deal with, without having to deal with other people’s broken code.
    • Lower quality of open-source software: in terms of quality, the argument made by open-source purists is that their software is of much higher quality than that of proprietary software. According to them this is due to the fact that open-source communities are larger and there are more people testing, spotting bugs and fixing them as opposed to small teams that develop proprietary software. This is based in Linus Torvalds’ law that “given enough eyeballs, all bugs are shallow”. That does indeed sound plausible, but on the other hand it seems to me like a bit of a contradiction to the many open-source companies that rely on services as their primary revenue stream. If the quality of open-source software is so incredibly high, then how do they make their money on services i.e. if there are no bugs to fix, the apps are easy to use and everything just works, then what kind of services are these developers selling to pay the bills? Developers creating proprietary software on the other hand have every incentive to write high quality code and create intuitive user interfaces, because if they don’t, then nobody will buy their software.
  • Paid for upgraded versions approach: an alternative to only offering services is to develop additional features into the open-source software and offer those features at a premium i.e. offering a “free” open-source community version as well as a paid for version with additional features that are enticing enough that make users want to spend money. Open-source can be fantastic when you want to lower your risk while at the same time increase the user adoption rate of your software. By open-sourcing your software you can start a project without having to take on the risk of starting a company, investing capital etc. and if there proves to be a high enough demand for your software, you can then take it to the next level by offering additional features and charging for them. This is the only time I would see open-source as good idea i.e. assuming that you actually want be compensated for your work.

In summary, before open-sourcing your software you should consider the number of features that you have in mind and whether or not there will ultimately be a demand for those features on the market. There are many apps that can be incredibly useful, but beyond their basic features there are a limited number of additional features that can be developed and incorporated into future paid for versions. A great example would an SDK (Software Development Kit) to interface with third party application or hardware: there are only so many features you can add to such an SDK. This kind of software with limited useful features should either be open-sourced without any intention of ever making money or it should never be open-sourced, but rather be released and sold as proprietary software right from the start.

What is the best path to follow in learning how to code for the first time?

Posted on by Paul Kolozsvari in Business, Management, Software

In my previous post on “How to become a very good programmer”, I mostly focused on how to set a direction for your career and the psychological process of getting the cogs turning in path to learning how to code.

However on a more practical note; once you’ve come up with an idea for an app you’d like to develop, you need to decide on the quickest learning curve for developing a complete end-to-end working application. At this stage you will need to consider a few things:

  • Technology Stack: which programming languages, technologies and SDKs (Software Development Kits) you will use to develop your app.
  • Design Patterns: aside from just learning one or more programming languages and their syntax, most technology stacks require you to understand at least the basics of certain design patterns e.g. OOP (Object Oriented programming), MVC (Model View Controller) etc.
  • Type of app: what kind of app are you thinking of developing; a mobile app, desktop app, web service, console app, or web app?

Now, assuming you’ve never written an app before or never even so much as written any code before, your biggest problem would be that you don’t know what you don’t know. Meaning that you cannot make decisions about technology stacks, design patterns and the type of app you want to develop because you probably don’t know what the implications are behind your decisions. Nor do you know how long the learning curve would be based on your decisions.

So chances are that you’ll probably go around asking people what kind programming language or technology stack you should start learning. Some of your programmer friends will suggest certain programming languages, but their suggestions will be nothing more than their own preferences. For example: your straight and narrow corporate type friend will suggest you learn Java or C# because they’re in demand in the business world. Your hipster friend will suggest you learn Ruby on Rails because it’s cool, while your book smart friend will give you a lecture about compiled languages vs scripted languages, or managed vs unmanaged languages. Last but not least, your really smart and technical friend who studied electrical engineering, but knows very little about business, will suggest you learn C and C++ for performance reasons. These people are all right from their own perspective, but the point is that you shouldn’t base your decisions on other people’s preferences/coding religions.

Instead the most important consideration would be the kind of app you will develop. Here’s why I say this: you may have considered developing a web application as your first app, but the problem is that in order to develop a fully functioning web app, you will probably need to learn a few languages. If for example you’re going with the .NET stack, you’ll have to learn C#, HTML, CSS, Javascript/JQuery, Ajax, SQL and maybe a bit of XML and/or JSON. That is literally 6–8 programming languages that you’d have to learn just to put together your first web app. As you can imagine, you will quickly become overwhelmed and disheartened, and before you know it you will give up and say that maybe programming is not for you. Instead of taking that route, I would suggest you chose an app to develop which will have the shortest learning curve, meaning that you can see things happen quickly which will keep you excited.

You need to develop the kind of app that can be coded in a single programming language from beginning to end. You could maybe start with a native Android app coded in Java, but the you’d have to know OOP (Object Oriented Programming) pretty well before you could get your head around the architecture of an Android app. The easiest would be a console (command prompt/terminal) app, but you might find that a little boring as a beginner seeing that there is no UI (User Interface). Based on personal experience, my suggestion would be to develop a desktop app using .NET Windows Forms and code it in some server side language such as C# (or even VB.NET). The UI is incredible easy to put together by simply dragging and dropping controls onto a form i.e. not coding for UI design. You thereafter simply double click on a button to get an event handler and type some code to make the button do something. This approach would enable you to develop an entire app from beginning to end with a single programming language and you could very quickly see your progress and it would also keep you excited. It would also allow you to get away with not knowing anything about OOP or any design patterns whatsoever. Once you’ve finished your first app, you could thereafter start branching out into web and mobile development using various different languages and technology stacks.

Productivity and creativity are like yin and yang

Posted on by Paul Kolozsvari in Business, Management, Philosophy, psychology

This may be a bit of a controversial topic which many may not agree with, but throughout my life I’ve come to the conclusion that productivity and creativity are a bit like yin and yang i.e. they are often indirectly proportional to each other.

As a kid, when I was in school, I was very good at maths and art. I was either terrible or average at almost all other subjects mostly because they didn’t interest me, but that’s besides the point. Like all students in South Africa, as I got further into high school I needed to chose which subjects to take/keep and which to drop. My father suggested I take a more technical path in my studies, which included maths, science, electrical theory and technical drawing. His reasoning was that a technical path would be more practical in the sense that it’s easier to make a living later in life by doing something technical rather than being a struggling artist, because generally speaking people are less willing or able to pay others to draw pictures. I loved drawing and being creative, but on the other hand, having immigrated to this country with only two suitcases and knowing what it’s like to be poor, I couldn’t dismiss my father’s advice i.e. making a good living weighed heavily on my mind. After much deliberation, I decided to drop art. When I went to varsity, I made the same decision when having to chose between studying Graphic Design and Computer Systems Engineering i.e. combination of software and hardware subjects (programming, electrical engineering, electronics, digital systems etc.). Throughout varsity I spent huge amount of my spare time producing electronic music. Although I loved coding, the feeling I got from making music was like no other feeling I’ve ever gotten in my life; it was like a drug that took over my life. After having started my first job, I once again made the same decision to drop the music in order to focus on coding.

I realized that in order to succeed at a particular thing in life, you often have to sacrifice other activities that you love doing. Therefore, aside from perhaps designing user interfaces and choosing the clothes I buy, I have done little to no exploring of my artistic/creative side ever since I started my career in software development. It is for this reason that not a day goes by where I don’t think about the decisions I have made. However, to this day I still believe that I made the right decisions and here’s my reasoning behind it:

All the way back in high school I realised that as much as I loved drawing I could not imagine being asked to draw/paint on demand for any teacher, lecturer, manager or customer. The same applied to making music; I couldn’t put a track together on demand. I could only do these things when I felt inspired. On the flip side, I could solve an equation, troubleshoot a technical issue or write some code on demand. Unfortunately, to make a living in this world people will expect you to produce on demand not just when you feel inspired. It is for this reason that I believe I made the right decisions in my life given my circumstances.

In the quest to make more money, I could have chosen to become a stock broker, a salesman or accepted a job writing software for banks. But instead I chose a career in software development, writing various kinds of software from mobile, to desktop, web and speech recognition apps for various types of industries. My salary will never come close to that of a stock broker, banker or insurance salesman, but to be quite honest there are limits to how much I’m willing to sell my happiness for.

In my view, software development serves as a perfect equilibrium for my personality: it is a combination of intellectually challenging tasks/features that need to be developed on demand while requiring a certain amount of creativity for designing elegant technical solutions and user interfaces.

This finally brings me to my point, that throughout my life I have often noticed that I am most productive when working on mundane repetitive tasks, while I am least productive on tasks requiring me to be creative; mainly because being creative requires extended periods of time thinking, day dreaming and searching for inspiration. As an example, one will probably find that asking a factory worker to drill holes all day will yield a large amount of productivity, which in turn will increase a company’s profits, but the person’s quality of life and happiness will diminish day-by-day. Inversely, you will find that asking even the most talented painter to create an original and world renowned painting every week/month will not prove to be a very productive endeavour.

In line with Joel Spolsky’s thinking, you can either be a world renowned chef like the Naked Chef or you can be McDonalds: Big Macs vs. The Naked Chef. Although I don’t agree with Joel’s bias towards the Naked Chef, I do believe there are some lessons to be learnt from his analogy. McDonalds’ main appeal to the public isthe speed (productivity) in which they prepare burgers and meals. What is not mentioned in Joel’s post is that McDonalds will always make more money globally than the Naked Chef because it requires less creativity and more productivity. A chef’s success on the other hand is fully dependant on talent and creativity, which cannot be scaled nor can new and original recipes be created on demand. The only caveat with aiming to be a world renowned artist/chef is that very few make it to that level, while most end up living off of coupons and hanging on to their pipe dreams.

So how does this apply to software development teams/companies? Here’s an example of two companies I worked for in the past, both consulting companies. I won’t mention any names, but it’s essentially a comparison of the Naked Chef vs McDonalds.

  • Cowboy Company: a small startup where I was the first employee. It was founded and managed by one of the most hard working, talented and creative software developers I’ve ever met in my life.
    • Work environment:
      • We were all encouraged to have a can-do attitude i.e. nothing is impossible, anything can be done and we can do it over night.
      • There were no boundaries between us and our customers in terms of budgets, time constraints etc. If the customer wanted a product developed that would typically take 6-12 months to develop, we told the customer we could get it done in two weeks at obviously a fraction of the cost that any other company quoted at.
      • Experimentation and hacking was encouraged i.e. software tools, utilities, programming languages, repositories, APIs, SDKs etc. were swapped and changed on a regular basis.
      • Little to no training was offered internally. If you were working on something new and involved a learning curve, you were regarded as an idiot if you asked questions.
      • The day-to-day work environment had zero structure, rules or processes. Thus it was the most chaotic work environment I’ve ever been in. For the first time in my life at the age of 24 my hair started falling out to the point that I was wiping my hair off the keyboard every hour on the hour.
    • Outcome:
      • Company outcome: the company was in existence for only about 18 months before we were told that we’re closing shop.
      • Reasons for the company outcome:
        • If creative people make for the worst employees to manage, then the same creative people make for even the worse kind of managers for the day-to-day running of a company. Here’s why: the process of being creative requires a huge amount of experimentation and trial and error. This experimentation process is unfortunately very counter productive because you’re not walking in a straight line, but rather zigzagging your way to nowhere in the hope that one day you’ll find the pot of gold.
        • Creative people make the worst kind of managers for managing people and budgets. Ensuring that money always comes in and that people get paid their salaries requires structure and discipline. Managing people’s productivity requires rules and methodologies to be followed in order to set expectations because as we all know the most common cause of unhappiness is unmet expectations.
      • What happened to the manager: this highly creative, talented and unstructured man ended up becoming the CTO of the world’s second largest gay social network, which he developed from scratch. Within a few years, they acquired the largest gay social network in the world. Needless to say that he’s become very successful in the end.
  • Structured Company: a large multi-national goliath of a tech company, with very rigid rules and regulations.
    • Work environment:
      • Highly structured and regulated work environment. Everybody had specialised roles knowing exactly what needs to be done with clearly defined goals and expectations.
      • A strong emphasis was put on training and documentation. Everybody was taught everything they had to know in order to get their job done. Asking questions was encouraged and the managers were always happy and enthusiastic about sharing their knowledge.
      • The management of people was pretty good; people were treated with respect, expectations were set and met etc.
      • The software consulting department I reported to was run like a well oiled machine, with projects being delivered on time and within budget. No major surprises ever came about (within the department), and every change introduced was carefully planned out.
      • Everybody was encouraged and directed to follow a straight line to success, which was great in many ways for your own mental health.
      • On the other hand, new ideas, strategies or ways of thinking were strongly discouraged. Internally, the typical company slogan was “this is how we do things around here” or “this is not how we do things around here”. In other words, there was little to no room for creativity or original thoughts … unless if course you were considered someone of importance i.e. you had a VP (Vice President) somewhere in your job title. Putting up your hand in QBRs (Quarterly Business Reviews) and mentioning my concerns and ideas often resulted in being laughed at or told that “you clearly don’t know how this company works”. Coming up with ideas for new apps or ways of generating more money resulted in being told that “it’s not your job to be thinking about that, don’t look to the left or to the right, just look straight ahead and do the job you’ve been hired to do”.
    • Outcome: over the course of a decade the revenues of this goliath of a tech company started dropping year-by-year. Eventually it ended up being cut up into pieces and sold off.
      • Reasons for the company outcome: innovation stagnates in an environment where creativity is choked in favour of productivity. The company stopped innovating and instead only released incremental improvements on their existing products. The people in the highest levels of management believed that the strategies that worked two decades ago will continue to work today. I personally witnessed such managers looking at spreadsheets in QBRs and scratching their heads as to why the revenues were plummeting. All the while blaming the sales people for not pushing more sales, without ever realising that you cannot sell yesterday’s technology for tomorrow’s prices.
      • What happened to the management: the company was acquired by another stagnant company, and they are still conducting their business the same way they always have, all the while still living in fear of their revenues dropping which continue to do so. To this day they still refuse to invest in R&D on certain technology stacks and prefer to purchase, rebrand and resell their partners’ products. Certain components in their hardware products are even purchased from their competitors. Due to these people being focused primarily on productivity and profits, their only concern are the earnings for the next quarter, and then the one after that. Short sightedness and puddle thinking is embedded into the cultures these types of older corporations.

The moral of the story is that companies which purely focus on productivity will always outperform creative companies in the short term, but they will never hit the jackpot. Creative companies on the other hand will always struggle in the short term and many will fall by the wayside, while a small minority of them will hit the jackpot in the long term. In the end it all comes down to high risk high rewards for creative companies and low risk low rewards for productivity focused companies.

On a more personal note, depending on your level in an organisation and your perspective, here’s what you can take away from the story:

  • If you’re an employee: part of growing up and maturing is the ability to come to terms with your own limitations. So you firstly need to know your own strengths and weaknesses and ask yourself whether you’re the creative cowboy type or the structured book smart type of person. Thereafter strive to work in environments where you are surrounded with like minded people. Personally I would advice you to work for a mid-sized company which is still in the process of growing, thereby offering opportunities to be both productive and creative.
  • If you’re a manager: as a manager you don’t (or should not) have the luxury of being biased towards either types of employees. Realise that you may have productive and creative types working for you and an ideal tech company requires both kinds of people i.e. you need the productive people to milk the cows, while you need creative people to invent new cows to be milked. Incentivise people accordingly. For productive types give them tangible goals and deadlines and you’ll probably learn that you’ll have to micro manage them. For creative types, give them a bit of freedom, a generous budget and time to play and experiment.

So summarise: productivity and creativity are indirectly proportional, but ideally they both are required for a tech company to not only thrive in the short term but also stand the test of time. Hence the I believe productivity and creativity are like yin and yang; they’re opposing forces but you still need both.

 

Technical engineering vs social engineering in a software project

Posted on by Paul Kolozsvari in Business, Management, Sales, Software

I started off my career in a product development environment; I sat behind a desk all day every day writing code. The only work related discussions I ever had to have was with the CTO (Chief Technical Officer). He told me what to do and how to do it. I was incredibly lucky to have fallen under his wing, because he was an incredibly talented developer and manager with years of experience. Not only did I learn a lot from him but I could always count on the fact that he always had answer to any problem I was facing.

However, in retrospect I realise I was working in a sheltered cocoon. Wanting to explore other opportunities I later moved on to a software consulting company. Soon after having started as a software consultant, I realised that I was in over my head. Interestingly enough, the technical challenges I was facing were relatively trivial compared to what I was previously doing. At the time I couldn’t for the life of me understand why I was struggling. Through experience, I later learned that the problems were not technical in nature, but they were rather social engineering problems i.e. I wasn’t in charge of managing the people on the project and even if I was, I wouldn’t have known how to manage them.

Every software project will always be made up of three major components:

  • Problem: at the core of every project is an underlying necessity for a problem to be solved.
  • People: there are expectations that are set out in every project by the stakeholders. These expectations are essentially agreements as to how a solution will be developed for the above problem to be solved. The stake holders involved in setting out the expectations are mostly made up of two crowds of people.
    • People requesting the software solution.
    • People providing the software solution.
  • Solution: once the expectations have been set out, they need to be met by the software developers i.e. developing the software that solves the defined problem according to the expectations that have been set out.

Most inexperienced software developers and business/sales people often believe that developing software for a customer/investor is all about the technical solutions that need to be implemented to make the customer happy. These kinds of people often accept the word of the customer as the word of God i.e. they walk around saying “the customer is always right” or the “customer is King”. Personally I believe they do this because they either lack the experience, a backbone and/or foresight. Hence they are “yes people” that often say yes to whatever the customer asks for, no matter how ridiculous/incorrect these requests may be and without considering the big picture. Hence they become a puppet being played like a ping pong ball by the customer’s stakeholders, and thereby ultimately ending up with a failed project on their hands.

Part of the reason this happens is because as kids, most of us are brought up to think that our superiors (parents) are always right and that they have our best interests at heart. When we enter the working world, we tend to see our managers and/or customers as our new superiors because they’re paying paying us. Therefore our natural instinct tells us to believe the same principle applies to them i.e. that the customer is always right. However, in the real world a consultant is hired to recommend and provide solutions, not to just simply take instructions. Simply put, the customer is not your parent.

Furthermore, as the name implies, each stakeholder has their own individual interests and incentives that motivate them. Whenever there are a multitude of varying interests, you can bet that there will always be conflicts of interests. Hence it would be foolish to allow the stakeholders to control the expectations and proposed solutions, thereby controlling the project itself. Your job as a consultant is to understand the needs of the businesses, the needs of each stakeholder, what motivates them and what their incentives are, so that you can gather enough information to make your own proposal for a solution. The consultant must be the one in the driver’s seat of every project.

Simply put: the consultant should never ask what needs to be done, but instead tell the customer what needs to be done and how it will be done based on the problem at hand. This means that at least 50% of the consultant’s work involves setting the right expectations, thereby requiring social engineering to be applied before a single line of code is written.

So what is social engineering in the context of software development?” Here a few points on this:

  • Understanding the customer’s business:
    • A customer will often request for technical solution to solve what is often only a simple operations problem. For example; in a warehouse they may request for software with a simpler and more intuitive process flow to be used by employees handling stock on the warehouse floor. Doing so may increase the productivity by 10-15%, but given the fact that according to statistics a warehouse worker spends 50% of their time walking to different locations, the more serious problem at hand are the long distances between the bin locations, rather than the process of data processing on a mobile device. In this example, software cannot solve the problem of the physical distances between bin locations, instead it can only optimise the existing processes which may be inherently flawed. As a consultant you need to understand these nuances and draft your proposal accordingly.
  • ROI (Return On Investment) & Budget: keeping in mind that that the primary aim of most businesses is to make money, the need for most software projects comes down to a necessity to optimise current processes by cutting costs and increasing productivity. Hence, any recommendations should be applicable to the customer’s business needs i.e. do not make recommendations to develop features just because it would be fun for you to develop them.
    • ROI: any feature to be developed, needs a cost associated with it and an ROI to be proven i.e. the customer is paying X amount to have this feature developed, therefore how much money will they be saving and how long will it take before the feature is paying for itself?
    • Budget: you also need to keep in mind that although you may be offering a great solution and a great ROI, the customer you’re proposing the solution to may not always have the budget to invest in it. This applies to any sort of business. For example, someone may present you with a bargain to purchase a block of flats that you can rent out and get a fantastic ROI, but if you don’t have the budget to make the investment, it really doesn’t matter how great the solution/business opportunity is. Hence, you should never be shy to discuss the budget with a customer upfront. This will prevent you and the customer from wasting each other’s time.
  • Understand your audience: IT staff for example, are more concerned with the network and IT infrastructure of your proposed solution than the usability or how it improves the business. Finance people are more concerned with the costs and ROI than with the actual features being offered by your solution. Operations people are more concerned with efficiency of the solution rather than the costs or technical architecture. Finally, end users are more concerned with the features and usability of the solution than with any of the above. You need to pay careful attention to who you are talking to at any given time as well as what you say, how you say it and what questions you ask.
  • Managing expectations: customers often do not understand the implications of developing software, such as the amount of effort and time that will be required. Based on that you should not allow the customer to dictate how long something should take and how much effort will go into it. As a software developer, it is your job to inform the customers of the above and be firm about it. They must accept your estimations or go somewhere else. Needless to say that the estimations and expectations you set should be reasonable and some flexibility (within get reason) on your end will prove to go a long way.
  • Getting paid: finally you need to worry about when and how much you will get paid. You will come across many customers that expect you to work for free with only a promise or a maybe of getting paid. Therefore it is imperative that you address this question with the customer right from the start in order to set the right expections. Also keep in mind that many customers that deal with software consultants are often under the impression that they are buying software, which couldn’t be further from the truth i.e. they are not buying software, they are buying your time and expertise which you need to make crystal clear to them right from the start.

To summarize: a software project is more than just someone telling you what feature to develop and then coding it. Therefore it is imperative that you understand the social engineering aspects so that you can manage the customer instead of the customer managing you. With the above said in mind, half the project is performed in boardroom discussions and over emails and phone calls, not just behind a computer simply writing pretty code.

Will software developers continue to be in high demand in the future?

Posted on by Paul Kolozsvari in Business, Management, Philosophy, psychology, Sales, Software

These are some of the trends that I have seen over the years:

  • Data agnostics software: if you’ve ever spent time jumping from project to project developing custom software for various customers’ requirements, you will pretty quickly come to the conclusion that you’re basically developing the same software over and over again and the reason you’re doing it is because each customer has different business rules. So to make your own life easier, you will inevitably start thinking about removing the business logic out of the code and making the software more and more customisable thereby making it data agnostic so that it doesn’t know anything about the data its working with. By developing data agnostic software, you are basically handing over the power and responsibility to your customers enabling them to implement the business rules themselves instead of relying on you to change code every time they change their business rules. Doing this is all good and great for the customer and even for your own company, because you can then resell your software to many more customers without having to code business logic for each new customer. However, the problem is that other competing software companies that are still coding custom business logic will be blown out of the water by you i.e. their customers will now rather just buy your out-of-the-box and customisable software from. The end result being that there will be less and less demand for software developers building custom business applications. That is why for example most corporates prefer implementing large systems like ERP, CRM, WMS, CMS etc. that are trusted and have been proven to work as opposed to developing their own system from scratch. Although these large software systems are more and more business logic and data agnostic, for the time being there will still be a need to have technical people installing and customising these “out-of-the-box” products. However the “technical” people required to do so will be less and less technical i.e. less and less technical skills will be required to perform customisations for each customer.
    • Example: back in the 1990s, if you wanted a simple company website you would have hired a web developer to put together a few HTML pages i.e. Home, About, Contact Us page etc. At some point, some clever guys decided to develop a CMS (Content Management System), which is exactly that: a data agnostic piece of software that doesn’t know or care about what content you’ve got, but it gives you the power to configure it yourself. You would still need an IT guy to perform the configuration and handle the hosting, but you no longer needed a web developer.
  • SAAS (Software As A Service) & PAAS (Platform As A Service) in the cloud: to make matters worse (or better , depending on your perspective), these large systems (ERP, CRM, WMS, CMS etc.) are now being moved into the cloud and offered as a service i.e. monthly payments to access the software online. That means that business people no longer even need technical IT staff to manage the hosting or to install and configure anything because that is now handled by the SAAS providers. Thus, once again making more technical people redundant.
    • Example: at this point the customer no longer even needs a CMS hosted on their own server. Instead they can just create their own website on wordpress.com without having any technical knowledge. If integration with a payment portal is still too difficult, they can even use Facebook Store or shopify.com.
  • Platform agnostic software: I started my career in mobile development, back when the popular operating systems available to develop for were Symbian and Windows Mobile/CE. If someone wanted a mobile app developed, they would have needed to hire a developer to code the app from scratch. Coding an app for Symbian was incredibly difficult with a 6–12 month learning curve, Hence requiring highly skilled Symbian C++ developers. In the company that I was working for, we were developing a .NET Compact Framework to run on Symbian, thereby allowing less skilled .NET developers to write code targeting the .NET Compact Framework and thereafter run that same app on Symbian. The very same people that I was working for ended up starting another company (devicemagic.com), allowing people with limited technical skills to put together a mobile app that will run on any of the popular operating systems like Android and iOS. Once again, if your requirements for a mobile app are relatively simple (data capturing, taking pictures etc.) then you no longer to hire expensive iOS, Android or .NET developers to build the app for you.
  • AI (Artificial Intelligence): at this stage AI is still a baby, but the baby is growing. Once fully grown it will further exacerbate the situation where we might see autonomous software writing code by itself based on your specifications. With AI programming languages will not even be needed anymore because the only reason programming languages exist is to enable humans to define the execution of a program. If the machine is generating the code, it will simply generate binary code.

The moral of the story being that it’s survival of the fittest i.e. the big fish will continue to get bigger by eating the smaller fish. The name of the game is consolidation; of technology, money and power. But to be fair humans have been playing this game since the beginning of time to the point where the little people on the ground get fed up and come out with their pitchforks, after which war breaks out, people die, everything gets destroyed and the survivors start rebuilding everything from scratch thereby starting the cycle all over again. But even knowing this I still can’t stop myself from recoding that function in my code to remove the business logic so that I can reuse it with my next customer.

To answer your question: as long as software still exists in this world, there will always be a need for software developers, but personally I think that the demand will drop in the long term. In a few decades, only the most talented developers will have jobs and they will most likely be working for the big fish, like Microsoft, Apple, Google, Oracle, SAP etc.

Knowing this, what can you do about it if you’re currently a software developer? The answer is; not much … except enjoy the proverbial gravy train that you’re currently on.

In the interim: focus on the following caveats of the above mentioned trends/technologies:

  • Security & Trust: there are still plenty of companies out there that are hesitant to move their data and infrastructure to the cloud. This especially applies to financial institutions which hate the idea of putting their money (numbers) into the cloud hosted by a third party. Their concerns being centred around the security of their data and whether or not they can trust the cloud hosting providers with their data/money.
  • Control: many of these companies are still run by control freaks that want highly customised software that works exactly the way they wanted to work. They will never be able to get that with so called “out-of-the-box” solutions. Thus they will still require highly skilled developers. For how long … only time will tell.

For the future: plan ahead by deciding between two different paths:

  • Technical: if you decide to stay the course and focus on being technical, then you better make sure that you are part of the best of the best. Average won’t cut it if you’re planning on working for one of a handful of tech companies in the world. Keep in mind that age will catch up with you sooner or later, and competing with twenty something year old guys that have no family, commitments or a life for that matter, will prove to be incredibly difficult.
  • Business: alternatively, you can become more business minded, worrying less about the details of software and more about how to sell it or manage the people implementing it.

Working for a software consulting business vs being an engineer in a product development company

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Software

Throughout my career I’ve come across many people who don’t fully understand the differences between a software consulting environment and a product development one. If you’re someone that has only every worked in one of these two environments, you might just be one of those people.

In essence; product development focuses on a single software product to be developed. Even if the company has a complete portfolio of different products, most engineers will spend their time on a single product for an extended period of time. Conversely, consulting businesses have smaller projects and typically do not develop software products, but rather customise existing large products and/or develop small customised applications specific to a single customer’s requirements.

  1. Product Development (Software Engineering): traditionally software was regarded as any other engineering endeavour: we create a product, we sell as many units of it as we possibly can and make lots of money. Microsoft is a great example and the original company to have implemented a product development approach.
    1. Disadvantages (of Product Development)
      1. Funding: The more time you spend in R&D developing the product the more value you will add thereby the higher the chances are that you will be able to actually sell it and the higher the price that you can sell it at. However, with each day that you spend in R&D the more money and time you need to invest while holding off on sales and profits until you have a finished product. Depending on the complexity of the product and value/features you’re creating, this R&D phase can last anywhere from a few months to a a few years. Simply put: you’ll need deep pockets.
      2. Risk: once again, with each day that you spend on R&D the higher the risk that you’re working on features that nobody wants, meaning that you will be wasting your time and money. Taking on such an endeavour is almost impossible if you’re starting from scratch, and thus most small entrepreneurs  look for investors in exchange for a slice of the pie i.e. a percentage of the company. In order to get an investor, you will need a really good idea for a product as well as a exceptional business plan for proving an ROI (Return On Investment) for the investor.
    2. Advantages (of Product Development)
      1. Focus: narrowing the scope of work in a product development environment allows the engineers to be a lot more focused. Instead of worrying about hours being billed, multitasking between projects, dealing with politics etc. they can focus on the task at hand which is to create technical solutions.
      2. High quality software produced: product development companies know that customers purchase their software products for no other reason than for the software itself and the features it provides. Therefore in order for such a company to survive it needs to provide finished software products that are of the highest quality and offer the largest amount of features.
  2. Software Consulting: a consulting business charges for services rendered, meaning that you’re not selling software but rather your time, skills and effort. The consulting business is very much like prostitution: a salesperson (pimp) sells the services of software developers (prostitutes) to customers and theses services are billed by the hour.
    1. Disadvantages (of Software Consulting):
      1. Limited time: with there being only 24 hours in the day, the amount of money you can make will always be capped. If you stop working, you stop making money.
      2. Unpredictable cash flow: business opportunities present themselves randomly in this line of work. You may have a period where you are presented with several projects at the same time, while there may be periods of drought where you and other consultants are sitting twiddling your thumbs.
      3. Unpredictable work schedules i.e. multitasking chaos: working schedules are difficult to follow when you have customers randomly calling you for support or new projects. Due to the fact that big money can never be made due to time constraints, you cannot always just reject an offer for a new project if you don’t have any people available at the time. Due to unpredictable cash flow, it is difficult to hire dedicated staff to specialise in and handle only support calls i.e. if a consultant is going through a drought he can easily handle a support call therefore no need for support staff, but when that same consultant is doing 3 projects simultaneously the support call becomes a nuisance and a distraction.
      4. Limited energy: due to constant time constraints, consulting is a fast paced environment. People can only keep up with the pace for so long before they start running out of steam.
      5. Politics: due to the fact that consultants deal with a lot of people on a day-to-day basis, it is inevitable that there will be politics. Although it is advised to not get involved in the politics, that is not always possible when it affects the projects.
      6. High staff turn over: most employees want consistency and peace in their life. The above working conditions of a consulting business make for a very stressful environment that interferes with the well being of consultants and their families. Furthermore, an unpredictable cash flow often forces such businesses into retrenching employees or making them contractors i.e. “we’ll call you when we need you”.
      7. Limited quality of software produced: due to the chaos and time constraints involved in a consulting business, the software development lifecycle is often rushed especially when consultants are working on several projects at the same time. The quality of the software being produced is also directly proportional to the size of the budget, which is  typically set by bean counters and thus the software will only ever be as good as it needs to be.
      8. Limited QA (Quality Assurance): doing anything related to quality assurance is often side-steppepd, such as code reviews, unit testing, lab testing, UAT (User Acceptance Testing) etc. This further contributes to the often low quality software being produced by consultants.
      9. Limited documentation: specification documents and documentation in general is often treated as an after thought … if it’s even thought about at all. For this reason, the customer’s requirements are often misunderstood or lost in translation between the business people and technical consultants i.e. in translating functional requirements to technical requirements.
      10. Limited talent in the market: many people are aware of the all the above working conditions that make a consulting business an environment filled with chaos and stress. Highly talented software developers are often afforded the luxury of choosing between working for large and wealthy companies vs small consulting companies. Such highly talented people that have purely technical motivations will often chose to do product development as opposed to working in a chaotic environment. Having said that, there are may advantages to working in a consulting business.
    2. Advantages (of Software Consulting):
      1. Never a dull moment: due to the multitude of projects that a consultant will be involved in throughout their career, it leaves little space for boredom. Of course there may be some projects that are less interesting than others, but working with various kinds of people in various projects keeps things interesting if you’re the kind of person that craves stimulation.
      2. Improved social skills: the stereotypical antisocial IT nerds are rare in the consulting business and if they do exist they struggle to deal with or cope with the constant communication with customers. Software consultants don’t spend all day, every day sitting in front of their computers coding like product development engineers. The constant communication improves their social skills, which are pretty good skills to have in life, considering that this world is filled with people which are tougher to get along with than machines. These social skills can be used later in life to move into other roles e.g. analyst, projects manager, sales executive etc.
      3. Knowledge of various other industries: engineers in a product development environments live in sheltered cocoons not really knowing or being interested in other industries. Consultants on the other hand typically do projects for all kinds of industries e.g. banking, investing, logistics, warehousing, accounting, social networking, marketing, security, conservation etc. Consultants are are this forced into having to learn and understand each industry that they are consulting for. Over the years, this allows them  to accumulate a broader amount of general knowledge as opposed to purely technical skills.
      4. Financially significant to the company: in a product development environment the sales people are the ones in the frontline bringing in the money, while the engineers are treated as kids that are thrown into a dark room, given toys to play with and expected to do the “technical stuff” and innovate, while the sales people are sipping cocktails and playing golf with their customers/managers. Consultants on the other hand are directly dealing with customers and billing hours, which puts them in the frontline keeping the cogs turning.
      5. Glory: based on the fact that consultants deal directly with customers, they are often regarded as technical “gurus’ or “IT geniuses”. Of course this is a fallacy, but nevertheless technical people are treated with a lot more respect by managers and customers.
      6. A single person can often develop the software from beginning to end: due the relatively small size of the projects in consulting environments, the software can often be developed by a single consultant without having to collaborate with other developers/colleagues. Strictly speaking, the only collaboration typically needed is between the consultant the customer/manager to determine business requirements, timelines and budget. This often makes things easier and speeds up the development process. Lastly, it makes the developer a lot more fulfilled knowing that each piece of software they develop is their baby.
      7. Autonomy : consulting involves a lot of travelling and irregular work schedules. Therefore, generally speaking it is not the kind of job where one will constantly have a manager looking over their shoulder. This of course gives consultants a certain amount of freedom and autonomy. However, keep in mind that this freedom comes with responsibility i.e. consultants need to be self motivated and disciplined.

Not all software companies are in the software business

Posted on by Paul Kolozsvari in Business, Management, Philosophy, Sales, Software

Many people have the misconception that a software business is purely about developing software i.e. that as long as code is being written that is valuable to someone else, then money can be made. This may be partly true, but it is a very narrow sort of view on what it takes to generate revenues.

The question of “what are we selling and when should we request payment?” determines the type of software business you are working for and/or managing. There are three main types of software businesses:

  1. Software as a means to an end: there are many businesses that dedicate the majority of their resources (money, people, time) to developing software but they do not directly generate money from the the software itself. Instead the software they develop is nothing more than a means to an end to support and/or automate their primary business, which may be anything from marketing/advertising, to selling physical products or perhaps managing logistics. The quality of the software produced by these companies has less impact on their profits than the primary service/products that they provide. Here’s a few examples of large corporations already doing this:
    1. Google may for example develop software as part of their business strategy, but they are primarily just an advertising agency and they just happened to have found a way to reach a wider audience by developing a search engine. More recently they have started making money on Google Apps but it pales in comparison to their revenues on advertising through their search engine. They have indeed developed Android, the most successful mobile OS (Operating System) in the world, but as far I know they make a minimal amount of profit on it, while Microsoft gain the majority of the profits which Google have to pay out to them for royalties. Customers that advertise on Google care less about the features Google provides than the ROI (Return On Investment) they get from advertising on their search engine. On the flip side, the people using the Google search engine do care about the quality of the search results, but those people are not paying to use the software.
    2. Facebook too is nothing more than an advertising agency that have just happened to find a different way of reaching a wider world wide audience. They do this by attracting people to a social networking website, keeping them engaged and gathering information about their interests (likes). Once again, the paying customers don’t care so much about the features available on the software, as long as their advertisements are reaching the target audience. Facebook is not exactly in the business of developing software as it is in the business of connecting people and feeding them targeted advertisements.
    3. Amazon for the most part is nothing more than a shop/store that happens to be online and they have thereby managed to automate the process of selling products to a wider world wide market. Only as of more recently have they started selling software products and services such as AWS (Amazon Web Services), but this is not their core business. Again, the features provided by the Amazon website have little to do with their customer satisfaction; their customers care about the products available on the website and how quickly those products can be delivered to them. Therefore Amazon is not so much  in the business of selling software as it is in the business of selling and delivering physical products.
    4. Uber is simply a company that acts as a middleman managing taxis. They may as well be a personal assistant that helps you coordinate the travelling via a taxi: contacting the taxi driver, telling you where to meet, keeping track of distances travelled and of course keeping track of the costs. They just happened to find a way of automating this whole administration head ache by developing software. The customers using Uber once again don’t care so much about the features on the software, as long as they get a taxi to take from the A to B at an affordable price.
    5. Apple: is in fact a hardware company that just happens to have developed their own operating systems and developer tools as a strategic way of improving and controlling the performance of their hardware and keeping their users within their ecosystem. The same applies to every other OEM (Original Equipment Manufacturer): they may have internal software engineers, but they are not on the frontline of what keeps the company going.
  2. Software Consulting: a consulting business charges for services rendered, meaning that you’re not selling software but rather your time, skills and effort. The consulting business is very much like prostitution: a salesperson (pimp) sells the services of software developers (prostitutes) to customers and theses services are billed by the hour. A software consulting business is not purely in the business of developing software, but rather in the business of providing services and adding value to customers.
  3. Product Development: traditionally software was regarded as any other engineering endeavour: we create a product, we sell as many units of it as we possibly can and make lots of money. Microsoft is a great example and the original company to have implemented this strategy.  These kinds of companies are the only companies that exist purely for the purpose of developing software. The challenge these companies have is that they will not be making any money until the first product is finished and ready to be shipped off. Therefore it requires massive funding and involves great amount of risk. With this approach, customers are purchasing the software products for no other reason than for the software itself and the features it provides. Therefore in order for such a company to survive it needs to provide finished software products that are of the highest quality and offer the largest amount of features.

The moral of the story is that the activities of a company do not always have a direct impact on the bottom line, and thus do not necessarily dictate the the kind of business that a company is in i.e. employees can be spending 90% of their time developing an advertising platform, but if the money is made from selling advertisements, then the company is not in the business of writing software, but in the business of selling advertisements.

How do you become an indispensable programmer?

Posted on by Paul Kolozsvari in Management, Philosophy, Software

As a programmer, your work will mostly be split up between either maintenance and feature development. It is up to you to decide which of the two you prefer to spend more time on. If you write bad code, you will end up spending the majority of your time doing bug fixing. If you write good code, you will spend the majority of your time developing new features … and no, you will not run out of features to develop because there will always be room for improvement and it is human nature for people to always strive for bigger and better and more efficient. People who write bad code, are forever stuck doing maintenance and support and never move on to bigger and better features and opportunities. So people who write bad code are doing themeselves a disservice in the long term.

As for becoming indispensable; in my experience it’s impossible to be 100% indispensable, but there are things you can do to become more needed and being needed is not binary (needed or not), but rather something on a scale e.g. needed from 1 – 10. Replacing a programmer/employee always has a cost associated with it in terms of recruitment costs as well as knowledge transfer costs (time and material spent learning the existing code base and technology) . With that said, it all comes down to money for the employer/customer, who will ask themeselves “what is easier, replacing the programmer or carrying on paying him/her”? The answer to that question will determine how needed you are.

Becoming needed is only one aspect, while becoming useful is another. In many ways, striving to become needed will make you less useful and vice versa. For example, the easiest way to become more needed is to become more specialized. The problem with specialising though is that you have less to fall back on if the technology you’ve specialised in becomes irrelevant.

Become needed: specialize by setting yourself apart from the rest.

  • Stay away from mainstream technologies and companies: the more popular a technology is the more programmers/experts there are in the market for that specific technology. This obviously means that you will have more competiton. More competiton means greater supply in the market, which means lower prices/salaries for those programmers. When there are 1000 programmers like you lining up at the employer’s door, it becomes easy to replace you.
  • Focus on either leading edge or trailing edge technologies for the same reasons as above i.e. there are few that dig into and risk learning a leading edge technology. The same applies to legacy technologies where there is a shortage of skilled people. Nobody wants to learn legacy technologies because it’s not cool. Don’t try to be cool, instead try to be needed.
  • Find a niche market/product: there may be mainstream development stacks/technologies being implemented in niche markets/products, but there will always be small details that are learnt only through experience in that specific market. New comers will therefore have a tougher time getting up to speed.
  • Learn proprietary technologies: in other words learn technologies that other people cannot learn by simply browsing the internet or picking up a book at the local book store. These are technologies that can only be learnt from your company sending you on those courses etc. Once again this will set you apart from the rest.
  • N.B. with all of the above said, keep in mind that there is a tradeoff to specializing. The more you specialize the more needed you are, but the less usefull you become i.e. you may know a technology better than anyone else in the country, but if you can’t do anything else you are not that usefull.

Become useful: generalize by being able to do as many different jobs as possible. See the big picture by understanding the big picture as well as the details: most people focus on either the details (lines of code) or the design/strategy. You don’t have to be an expert at everything, but the wider you spread your view the better.

  • Business Logic: Even more importantly, understand the business rules of the software you’re developing. Any programmer with equivalent technical skills as you can take over your code immediately. However, learning the business rules of the software takes a huge amount of time and if there is limited documentation it makes it almost impossible for someone else to take over an intricate software product.
  • Design: Learn the design of the software, in terms of how all the components fit together to make up the entire system i.e. the web application, database, clients, services etc. As with the above point, anybody can come in and undertand a specific function in your code, but understanding the overall design of the software is incredibly difficult if there is limited documentation or limited knowledge transfer.
  • Sales: Learn and get involved in the sales/business aspect of your company, in terms of what it takes to sell the product and what the customers are looking for. Once again any other programmer can come in and take over some code, but being part of the sales cycle makes your more needed as well as more useful.