Month: September 2017

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.