// TheGoodCoder

Author: admin

  • Failing forward – thoughts on learning and wastage

    Failing forward – thoughts on learning and wastage

    Learning from failures

    We have all heard the startup success stories – The ones where people had a turnover of R 100 million within one year with a minimal amount of effort. 

    With this in mind, I am reminded of a friend who decided to start a coffee shop. He was going to make a small fortune. He spent quite a bit of money to get licenses in place, kitchen appliances, print menus, tables etc.

    Some businesses do not come cheap! After the opening night (which we celebrated with him), no business came through the door again. 

    His business failed.

    What really matters?

    Many people start analysing the situation and why they failed. Though analysis might be important, it often leads to analysis paralysis – even in the unpacking of the past.

    It’s often more valuable to ask the following questions:

    • What – what happened, what is the situation and what caused things to play out like they have?
    • What did you learn from it?

    Changing our thinking to learning enables us to get over our failures and move forward making better decisions.

    Wastage and learning

    If we use learning as a measurement of growth, it’s important that we learn the right things. We need to position ourselves and our business to learn as much as we can about our customers. 

    I am sure you’re saying: “Yes, but this is a great excuse that cannot be measured!”. The art of learning is focused on learning. We need to learn about things that matter. 

    Wastage in software development

    New features

    Historically, the software developer will receive guidance from the business analyst about what needs to be built, whereas the project manager will determine what is important.

    We know the following in the software development sphere:

    • Resources are expensive
    • Resources are scarce
    • Not all solutions are critical
    • A select few reports and enhancements are in use a few months after it was released

    With this in mind, what can we do to cut down wastage? For starters, we can ask:

    • How much value will this feature add compared to the development required?
    • Is this feature part of the critical roadmap, quick win or a nice to have feature?
    • If you’re fully agile or use lean methodology, ask how the idea can be tested without writing a single line of code?

    The goal is learning. Don’t write code unless there is definite proof of the value that it will add.

    Remember – the customer is at the heart of everything you do. 

    The support stream – BAU

    When running a business as usual (BAU) in the support stream, there are often a lot of issues at any one time that need to be resolved at the same time.

    In the IT space, we have support tickets on a Kanban board, agile methodologies and other restrictions to get developers to operate like machines. They need to push out code – which is often never used.

    The reporting team spend weeks aggregating data for reports – which are only used once – if ever.

    To avoid wastage, it’s vital to break down any support ticket to fit into one of the four urgent-important quadrants. Below is an example of where different tickets reside.

    Conclusion

    Business needs to focus on that which is important. 

    The way to measure this is by learning about what is truly important to our customers. 

    We should always learn from our failures.

    Simply be effective.

  • How to validate your idea or feature before you code

    How to validate your idea or feature before you code

    Validate your learning

    I recently received an email from a potential customer who has an idea for a business and required funding. Though the money was not a large amount, I decided to take a leaner approach to the situation to try and understand how we can cut away wastage and provide a cheaper, more effective solution. I suggested that she starts small and with what she had, but the person wanted to go big or go home.

    Many people don’t believe in the power of learning, yet disruptive innovation is filled with learning being valued more than money:

    • Airbnb had to learn which part of their system is not complimenting the stay-at-home experience. This included discovering handing over cash, relooking the quality of the venue photos and targeting people outside of special events
    • Netflix learnt about customer behaviour and building up a relational database of which shows would be more appealing after watching certain shows

    Where did validated learning come from?

    Eric Ries first coined the term validated learning in 2011.

    The idea is that you test whether a feature, product or enhancement will add the value that you think it will.

    This can be achieved by firstly realising that we are making assumptions about how much value a feature will add to a system. Secondly, we need to be able to measure the effect that it has on the user – will this feature move the business forward? Are we able to validate this without writing the feature?

    The validation process

    Though this is not a one size fits all, the typical steps in validated learning can be seen as:

    1. Specify a goal – add details about what you want to learn
    2. Specify a metric that represents the goal – define how you will be able to achieve it. Include details such as software or analytics trackers to be used, methods etc.
    3. Act to achieve the goal – do what needs to get done to get the metrics in
    4. Analyze the metric – do the results align with the initial goal? Will this give you the result you need?
    5. Improve and try again – what did you learn? How are you using that?

    Examples of validated learning in software development

    Validated learning makes sense in small businesses and entrepreneurship, as one can test it directly with the customer.

    In most companies, the developer never sees anyone other than the immediate IT team, it can be challenging to change the mindset from a cost centre to a team of enablers.

    Yet, with a bit of creativity, the developers or business analysts are able to work through the validated learning process without interrupting business as usual.

    Some of these include gathering analytics through Azure Performance Monitoring, Google Analytics, HotJar or similar software. This can be combined with A/B testing and other methods to see if a button is clicked on or not.

    The case of the vital feature

    An accounting online software as a service (SAAS) solution received feedback from clients that they require a fairly large feature. They decided to add a menu item with the name of the feature. When the menu item as clicked, it navigated to a page saying “Coming soon”.

    Using Google Analytics, they realised that no one clicked on the page – it wasn’t something that added value to their clients.

    The large app requirement

    A client required a complicated mobile app. To simplify the requirements, we analysed the features that we believed to be most important. We built this into an MVP to pitch to clients.

    The client was able to demo the app with the basic features and receive feedback about what the users expected. The developers were also able to get feedback via analytics software to understand which features were clicked on most and which were not seen as important.

    Conclusion

    Validating your feature as valid, value-adding and worth the effort means that the developer codes knowing that his code will make a difference.

    Creating MVPs, prototypes, using analytics to track user activity can give us insight into what is actually important.

    Simply be effective.

  • Lessons learnt from managing developers

    Lessons learnt from managing developers

    Software developers and management

    Being a software developer myself, it is always interesting what I discover managing other developers. It gives you perspective into behaviours which you have seen in yourself, your team, product owners and businesses.

    Software developers are seen as the mushrooms of a company – they get fed pizza and coffee in a dark room, and turn this into software. It’s also unknown what happens in this room, yet we see features, functions, new solutions and problems getting solved.

    Larger organizations tend to have a development or project manager who liaises between business and IT. This stakeholder management is sometimes insufficient, as the round trip of getting the needed information could take longer than the business owner would like.

    The product owner’s relationship with the developers

    In some cases, it becomes more convenient that the product owner contacts the developer directly. Yet, the impact is seldomly understood.

    In some cases, such as a specific incident it makes perfect sense, for the product owner to contact the developer directly, yet not everything is such an incident. For example, if one person cannot log in, it is not an incident, but if the whole company is coming to a standstill due to a system being down, it changes the scenario.

    When developers tackle complex problems, focus time is needed to get code done. It has been explained by some as ‘the zone’ or ‘the zen of programming’. In case of interruption (though only 2 minutes), this zone is destroyed.

    It can take up to 45 minutes to get back into the zone.

    I personally found it better to have a set time to get feedback from developers. all questions can be asked, but feedback should be expected at the set time.

    Time management

    We know that business owners want deadlines on delivery, but few developers are able to give exact timelines, especially with constant interruptions.

    For this reason, many developer teams take the agile approach. Points are assigned to a ticket, and then a certain number of points are agreed upon for a sprint of 2 weeks.

    It happens at times that the developers work strange hours. When they are in the zone, they could work through the night and have an amazing finished feature the next morning.

    Developers can easily also lose track of time and deliver something that was never asked for. For example, adding filters on tables and making obsolete fields configurable.

    Agility

    Developers like to code according to spec. In some cases, they can give estimates, but cannot see certain issues such as API integration issues and incidents that push the deadline forward.

    In my experience, it often happens that the spec and what the client requires are not the same. When the client is presented with the code according to spec, the requirements are changed so that it fits the requirements of the client better. In some cases, the underlying data structures need to change, and in others, UI design patterns have to be broken to accommodate the new changes.

    This tends to cause developers to make rude hand gestures and resign a job.

    To manage this is a delicate situation. It’s best to try to understand the reason for the developer pushing back. In some cases, there is a valid reason, whereas in others the product cannot function as intended without the new change to the original spec.

    Finding bugs

    When a bug is found, the terminology of communicating the issue is exceptionally important for a developer. One should never say things like ‘the issue is still there’ or ‘this is broken’ or type EVERYTHING in all caps. A better approach is to show the developer the problem and ask them if this is a bug – or if this is the intended behaviour. In some cases, it is how the system should function, and the product owner forgot about the business rule.

    On the other hand, I cannot deny that developers are sometimes overly sensitive and have an emotional connection with their code. To tackle this is challenging at the best of times, as this indicates dedication and personal involvement in the success of the product.

    It’s highly recommended to have a bug and issue sheet that is supplied to the developers at a given time, and not in pieces throughout the day.

    Crisis management

    Incidents happen.

    Some are bigger incidents than others.

    When speaking to a developer about an incident, they will be able to tell you how serious it is. Though we would like to believe that what we see is the end of the world, it might be a single case.

    Developers require a lot of information to tackle a problem. In many cases, the business owner has no idea what these things are. This could include a video, phone numbers, user Ids, time that it happened, screenshots and so forth.

    If the business owner has no idea what needs to be supplied, ask the dev – but try and get as much information as possible. I find that it’s sometimes challenging for business owners to find the details required. For example, if an end-user of a mobile app is having issues, it’s difficult to call them multiple times and ask for screenshots, phone model information, app version and which brand of toothpaste they are using.

    Conclusion

    Working with developers can be a sensitive issue.

    Managing clients can be challenging, especially when they require certain details immediately.

    Finding the middle way is challenging, but is the only way to move a project forward with speed.

    Simply be effective.

  • Getting your software solution to market faster

    Getting your software solution to market faster

    When you have no time to spare

    Startups and small businesses often don’t have the budget, resources and expertise of large corporate businesses. This limitation can become the greatest strength by applying lean software development principles – eliminating waste and delivering only what the customer needs.

    Even though many developers love giving customers more than what they need in an attempt to under-promise and overdeliver. When developing for getting a product to market, all unnecessary elements need to be removed from the equation.

    This might include theming, customising, features, data filters, and other elements that might not be critically important for the customer right now.

    Needs analysis and focus

    A developer that works at a startup often needs to work long hours and deliver more than just code. To optimise the time spent as well as the effectiveness of the output, the developer need understands the customer needs to fulfil them appropriately.

    Needs can be analysed and discovered in many ways: Hotjar, Google Analytics and other tools offer us an insight into how customers interact with our solution.

    Startups and small businesses often have a low level of certainty concerning their customers’ needs. It would therefore make sense to take a leap of faith assumption and start testing their needs (and the assumptions that we make).

    Lean software development

    Lean software development is all about cutting waste and testing our assumptions about our clients, our product and the industry. The following is an outline of the process:

    1. Eliminate waste – determine what is actually important. Cut out unnecessary features or enhancements that are not critical.
    2. Amplify learning – Don’t spend days doing documentation and planning sessions that don’t deliver results. Have short iterations with regular customer feedback cycles included?
    3. Decide as late as possible – when dealing with uncertainty, it might benefit the client to create bite-sized solutions first – and therefore deferring larger decisions of the end product until more is learned of what is actually required.
    4. Deliver as fast as possible – time to market is crucial in getting user feedback. It, therefore, makes sense that any tools, plugins and other means must be used to move the project forward.
    5. Empower the team – allow software developers to make decisions about what their validated learning has proved to be correct.
    6. Build in integrity – The customer needs to be at the heart of what is done. The product must solve a specific problem. If the problem is solved successfully, it will build trust in the company and product. This, in turn, will build integrity so that the marketing, software and image all contribute to the same solution.
    7. Optimise the whole – Issues in software can damage the integrity of the software and brand. It is therefore vital that integrations with third parties, bugs and issues are prioritised on the urgent-important scale, where the most important and most urgent issues get the first attention.

    Think big, act small, fail fast; learn rapidly

    – Mary Poppendieck

    The minimum viable product (MVP)

    Many clients have the viewpoint that the only way to go to market is with a fully built product. This, however, can easily ruin a small company or startup financially.

    To the first paying client, one can create a minimum viable product to test their hypothesis and problem statement.

    For an MVP, the developer can use any means within reason to speed up output. The MVP could be something as small as a WordPress site with WooCommerce.

    One could easily test the use cases with WordPress – developing plugins and reporting for many cases. Once viability is determined and the system outgrows the MVP/prototype, a custom bespoke solution can be developed for more complex systems.

    Note that in some larger corporate solutions, the MVP might be a six-month project for a team. The focus should be on determining and developing what is actually important.

    For example, if a large life insurer would like to bring to market a tool to help financial advisors predict retirement income, a simple spreadsheet might be the first stop to see the reactions and needs of the financial advisors. When the solution is ready for coding, one could easily set up a simple front end with chart components and code back end that opens, writes, reads and calculates the values from an excel file before it’s translated into code.

    Tools to speed up delivery

    There is a plethora of software plugins, DLLs, open source projects and code snippets available that can assist in speeding up delivery.

    It’s worth doing a quick check for open source solutions available that could be used as a base for the MVP.

    Here are some ideas to get a project off the ground:

    • Base software – WordPress, DNN, open source CRMs and built in framework functionality (e.g. .NET Identity for authentication) can speed up a project to get it off the ground faster.
    • Front end plugins, libraries and frameworks – Jquery, Angular, Bootstrap, datatables.net and Telerik could also assist in meeting requirements for lean testing.
    • Dev-ops – Continuous integration tools (TeamCity, Jenkins), Continuous deployment (Octopus) and logging services (ElasitcSearch or appcenter.ms for mobile apps)
    • Cloud solutions such as Azure and AWS offers many services, functionality and APIs to speed up development

    Conclusion

    For many startups, the focus is on getting to market as soon as possible. They do not always have the time to wait six months for bespoke development.

    Rapid application development tools can assist developers in getting a customer’s product to market as soon as possible.

    Though one needs to weigh up the impact this might have in the long run, once the company’s cash flow is there, more enhancements can be added to the list.

    Simply be effective.

    Sources consulted

  • Writing code and doing dev-ops for stability

    Writing code and doing dev-ops for stability

    When stability is everything

    When you write code, make it future-proof.

    In many industries, the stability and consistency of a system are critical to business success. Yet, we require changes to be made without affecting stability.

    As a software developer, one is able to make strategic choices to optimise a solution for stability. Versioning and rollback strategies, unit tests and simplifying code can all assist with confidence in the solidity of the solution.

    Unit tests and automation tests

    Unit tests essentially test certain scenarios to confirm that the code will react in the desired way. If the unit test breaks, it means that the changes should be relooked, or the unit test changed to fit the new business rule.

    When a developer adds unit and integration tests, it will empower him to know when changing something in a solution will break the existing business rules.

    If the resources allow, an automation tester can add tests on the user interfaces. This is a fail-safe for unit tests, as often unit tests do not cover user interactions.

    If unit tests are combined with automation tests, this will empower software developers and business owners to become more confident that deploying code will have the desired outcome.

    Deployments and dev-ops

    A $460 million dev-ops disaster

    Knightsbridge, a forex trading company didn’t have a proper deployment strategy in place. One evening, they deployed code to their servers. Having multiple servers to deploy to, they forgot to switch a flag off on one of the servers. Here’s a quote from the US Securities and Exchange Commission filing:

    “During the deployment of the new code, however, one of Knight’s technicians did not copy the new code to one of the eight SMARS computer servers. Knight did not have a second technician review this deployment and no one at Knight realized that the Power Peg code had not been removed from the eighth server, nor the new RLP code added. Knight had no written procedures that required such a review.
    SEC Filing | Release No. 70694 | October 16, 2013

    Knight Capital Group realized a $460 million loss in 45-minutes.

    Devops

    It makes sense that the deployment process needs to be automated. For this reason, software such as Octopus deploy and continuous integration (CI) solutions such as TeamCity, Go Pipelines and Jenkins , that do automatic builds, run unit tests, etc.

    It is also advisable to have one-click deploys, implemented with a blue-green strategy, where the solution will only deploy if all steps were completed successfully.

    Versioning and deployment

    Many managers who have to deal with unstable code believe that not upgrading or deploying new code is the answer to keeping the status quo. This is, however, not possible in the fast-paced digital businesses of today.

    It is therefore advisable when deploying new changes to a codebase that is unstable, large and/or complex, one needs to know exactly what will be going live. For this reason, it’s important to have a proper deployment process in place, including source control logs of all changes.

    Having all this information available will not only give a  developer the ability to find bugs faster (as he knows the changes that happened) but also give the product owner peace of mind about what is currently in the production system.

    Simplicity

    If you write less code, then there is less code that can break

    Making the codebase smaller by deleting code that is unused, deprecated and/or duplicated can lower the risk of issues sneaking in. For example, the IDE’s IntelliSense might tell you that certain methods are available, while they are not in use.

    When writing code, it is advisable that best practices need to be followed with regards to naming conventions and code structures. It would not only be easier to debug, but any changes to the code can be made with clarity, rather than guesswork.

    Developers are able to simplify code by constructively refactoring like refactoring large methods into classes with smaller methods.

    Should I upgrade/update often?

    I once worked on a solution that was running a version of SQLServer that was 20 years old. We were explicitly told that the solution was a critical business system.

    Not only was this run on a PC where the operating system had no more support updates, but it was also itself not upgraded.

    Concerning upgrading a system, the options and impact are as follows:

    • Never upgrade
      • this will cause certain devices and browsers not to display the app properly
      • The risk of hacking and errors on the software, operating system and infrastructure is greatly increased.
      • The code might be stable for the time being but will require a total rewrite when the existing system cannot work as expected anymore
    • Upgrade major versions
      • Code without unit test coverage might be unstable with the next release.
      • The code lifetime is lengthened
      • More work will be required to make the major upgrades due to deprecated functions
    • Upgrade on a regular interval (6 monthly or annually)
      • Code without unit test coverage might be unstable with the next release, but the impact will be smaller than upgrades with major releases.
      • The code lifetime is lengthened
      • The changes are broken down into smaller, bitesize chunks

    Conclusion

    Software stability in some scenarios are vital to some business. For these businesses, it makes sense that they have the proper infrastructure in place to cut out any human error.

    Using proper unit, integration and automation tests could prevent complex business rules turning into a crisis.

    Though one might consider never upgrading a system, it needs to be understood that this might be delaying the inevitable – rewriting and/or refactoring code.

    When stability is important, make sure proper due diligence is done and processes are in place to stop rogue code being promoted to production.

    Simply be effective.

    Sources consulted

  • Writing code for maintainability

    Writing code for maintainability

    Someone will need to maintain your code

    Most of the effort in the software business goes into the maintenance of code that already exists

    Wietse Venema

    Most developers are generally not satisfied with being stuck in a job where they need to handle only support. The idea of a fresh new solution that needs to be created and formed is exceptionally tempting – and many developers will leave a job to get away from the support.

    To prevent a high staff turnover, it’s vital that developers need to write sustainable, maintainable and understandable code.

    Write code as if the person that will maintain your code is a murdering psychopath.

    Many contractors and businesses are focused on delivery – if the application is not in production and working, then it’s not finished. For this reason unit tests, naming conventions and clean code is often sacrificed for early delivery.

    Maintainable code and code smells

    Uncle Bob famously compared writing code to a chef preparing a meal. He would sometimes need to multitask and check that everything will be ready in time, the food will be hot and that the presentation is perfect – and most of all, clean up as they go along. When they present the final dish at the end, the kitchen behind them is clean. In the same way, developers need to clean as they go.

    When maintaining code, developers always need to leave code in better condition.

    When bug tracking, it often happens that you look at a piece of code and think “What in heaven’s name…?”. This is what we call a code smell – and often technical debt. It is in the interest of the developer to clean up as he goes along – and a code smell should be the starting point to do a little refactoring or cleaning.

    A code smell is a surface indication that usually corresponds to a deeper problem in the system.

    – Martin Fowler

    Code will only be maintainable if we constantly take a little time to make it cleaner when we touch it. Note that the aim is not over-engineering, but sometimes even renaming a method or property will allow the code to be more readable.

    Patterns & practices

    When optimising for maintainability, developers need to focus on following good practices and design patterns.

    These include a standard for naming conventions of methods and properties. Here are some pointers:

    • Follow SOLID principles – more info here
    • Do not abbreviate methods or property names
    • Don’t repeat yourself – don’t write the same code more than once.
    • Simplify the code base – code that’s not there cannot break
    • Be clear in your naming conventions – for example, Validate() is not a clear method. What is it validating? How can we rename this to be clearer?

    Separation of concerns

    Oftentimes a piece of code starts expanding past what it was originally designed for. This is normal, but it’s recommended that once this is noticed, refactoring needs to take place. Here are some thoughts on the separation of concerns and refactoring:

    • Keep your methods small – only a couple of lines if possible. This will make it clear what the methods are doing. When you find that a method becomes too large, it is often a sign that it breaks the single responsibility principle. Extract these into smaller methods
    • Avoid reuse of tables in a database with different elements that are not of the same type – for example, when you have a table with containers, don’t reuse the table for moulds, inventory and car parts. Even though it might look like the fields reuse would be a good idea, it can become unmaintainable in the long run.
    • When building user interfaces, keep different concepts in different places. For example, don’t add cars, houses, chickens and users in the same list and allow for editing these. From a usability level, users need to get used to where to find users, livestock or assets.

    Dependency Injection

    Though there are many opinions about dependency injection, it’s worth noting that interfaces with implementation assists in decoupling software and allowing developers to swap out the implementation of classes, without any massive code changes.

    As dependency injection is linked to inversion of control (SOLID principles), it’s a good practice to do in a project, especially if unit tests would be required.

    Unit tests

    When a change request is actioned, everyone needs to know that the changes will not affect other parts of the system. This is especially important where a client has a complex calculations engine such as insurance policy premium calculations – this should not fail, as this could mean the difference between profitability and legal action.

    With a plethora of unit test solutions that can seamlessly integrate into any codebase, it’s becoming easier to write tests to make sure that processes and business rules will be followed, and throw an exception if any error occurs.

    Integrating unit tests into continuous integration can also help developers to pick up issues long before it reaches production.

    Conclusion

    Solutions grow over time. More functionality is often required and needs to be added.

    Having well structured, clean code with unit test coverage can assist in picking up issues long before they could happen.

    Maintaining code requires consistency, and therefore it’s a prerequisite to have best practices in place. The expectations and standards need to be clearly defined so that all parties are aware of what is expected.

    Simply be effective.

    Sources consulted

  • Writing code for performance optimisation

    Writing code for performance optimisation

    Slow systems and systems slowing down

    We all know the call from a client telling you that the software has become so slow, it’s unusable. Yesterday it was fine, but today it is a disaster. It’s not that the code has a life of its own, but reaches a tipping point where performance degradation has eroded to the point of unresponsiveness.

    Generally speaking, systems tend to get slower over time. Data sets grow, libraries get upgraded and code expands to fit business needs – one or all of these factors can influence the performance of a system.

    What is performance optimisation?

    Before we start, let us look at what is performance optimisation.

    In a nutshell, performance optimisation is the process of making slow computer systems faster. This could have different meanings, including making code, software or other changes:

    • To allow  rapid execution
    • Operating with less memory storage or other resources
    • Working more efficiently

    The focus here is on making the software more responsive and executing more rapidly.

    Levels of Optimisation

    The performance issue can be on one or many different levels of optimisation. The higher levels tend to come early on in the initial building of the software. for example, if a solution has been built on a NoSQL database and later on it’s discovered that it cannot handle 100 Billion records, and architectural rethink can be challenging.

    The issue could sometimes be on lower levels, such as a bug in a plugin/code library that causes slow response times.

    Here is an overview of the levels of optimisation:

    Design level – on this level design/architectural choices are made. For example, if a system has a strong dependency on network calls, it is best to optimise the solution to as few as possible calls over the network, yet still getting all the required data.

    Algorithms and data structures – The way that data is persisted in a database could affect the SQL execution paths as well as sorting and filtering algorithms. It is therefore advisable to plan these structures well before implementation.

    Source code level – Some languages do not have automatic garbage collection (disposing of used objects/code). Another example: x ^ 2 can be written as x * x. As systems could grow exponentially, this could potentially cause a great headache.

    Identifying improvements

    Debugging and finding the slow issue

    identifying ways to improve software performance is as much an art as it is a science. In most cases, a system’s performance normally starts with improving just one or two aspects of the system’s performance. This could be execution time, response time, memory usage, disk space and so forth.

    Depending on where the improvements are needed, a different solution could be required. In general, developers tend to spend their time in the source code level.

    Here are some examples of encountered cases:

    The front end of a web application is exceptionally slow. The user attempts to select a field from a dropdown, yet the dropdown takes 1 minute to load.

    • We need to uncover if the issue is in the database layer, an architectural issue or a front end issue
      • If the stored procedure is slow, it means that the issue is either in the database structure or stored procedure
      • If the stored procedure runs quickly, then the issue is either in code aggregation/arithmetic, network or the plugin

    Web optimisations

    Websites and web applications can have many issues that are out of the software developer’s control. This could include internet issues, browser incompatibility and users not understanding how to use the software.

    There are however tools that developers can use to understand user behaviour, performance issues and slow connections (such as the F12 Developer tools), as well as optimizations that can be done. These optimisations include:

    •   Adding GZip compression for faster file transfers
    • Image optimisation by saving for web and devices on photoshop as well as splitting out the main server and the image server.
    • Implementing AJAX calls with spin wait animations to make it seem like the page is loading faster
    • Caching of data – one can include caching server and browser side so that round trips to the database or server could be reduced.
    • Using local storage on the browser for lookups and other information.

    Proactive external tools

    In many cases, it’s easier to be preventative and using solutions that help in identifying slow parts in a system. For example, Azure performance monitoring allows for capturing a log of information about slow response times and errors that might occur.

    It’s also advisable to have a logging database (or logging service), as this might give insights into timeouts and other issues.

    There are also many database preformance tools available: some built in, such as RavenDB’s health dashboard and SQLServer’s execution paths that can help a person to bug-track.

    The RavenDB Dashboard for performance monitoring

    The trade offs for performance optimization

    Even though reasonable precautions can be taken to avoid slow code, it’s not always the best solution to start optimising code prematurely. Optimising code before this is an issue can cause unnecessary delays in delivery and wasting precious time.

    Some code best practices could actually slow down code. For example in large systems loosely coupled code paired with external libraries implementing dependency injection could contribute to a slow system.

    Conclusion

    Careful planning and consideration need to be given when starting out on a project. The architecture, infrastructure and technologies need to be chosen carefully, to align with the goals of the software.

    Once an issue with performance surfaces, it needs to be investigated, the root of the issue determined and the issue resolved.

    Though this sounds like an easy task, it’s not necessarily something quick.

    Simply be effecitve.

    Sources consulted

  • Writing code so that your software can be dynamically configured

    Writing code so that your software can be dynamically configured

    Choosing to optimise for dynamic configuration

    In the last few years, dynamic configuration has become more important in software development architectural decisions. The reason for this is the need for business and product owners to be able to change the behaviour of a system without delay or deployment.

    In many scenarios, it is not economically viable or actionable to stop a live system to make changes. With deployment cycles sometimes lasting months, the need for important and urgent changes needed can be a huge headache in a company.

    It is for this reason that the architectural decision is taken to make functionality dynamically configurable.

    Complex problems needing configuration

    Understanding dynamic configurable systems is best explained at the hand of examples.

    I have previously worked on a rules engine where all rules were saved in a SQL Database as strings. C# would evaluate all the rules and return the result.

    Another example is companies requiring dynamic forms, depending on a large list of variables. This happens quite often in the insurance and financial services industry – the business rules are complex.

    In both these scenarios, the data can change quickly – and the system needs to allow for this.

    Software configuration examples

    With the extreme cases above, let us look at other examples where dynamic configuration can help software be more flexible:

    • Software developers can add code to toggle functionality on or off
    • Security, roles and permissions can be handled by a user interface. This will cut the developer out of the process
    • Dynamic forms that will allow the system to display what is necessary with a large set of variables can be added.

    Why would configuration be a bad idea?

    Writing highly configurable code can allow for fluid and dynamic systems yet is not necessarily fit for every product:

    • The overhead and time spent on the initial solution can cause delays in getting the product to market
    • Unless the coding stories are broken down and monitored, it can allow for scope creep and over-engineering.
    • The benefit does not outweigh the effort
    • Depending on the implementation, there could be a performance impact that would be challenging to debug.
    • Configuration can in some circumstances make code more complex and provide job security to your developers
    • For complex systems such as rules engines, the business logic is moved into the database. This will lower the unit test coverage, as changes can be made to the rules on the fly.

    Planning for configuration

    It is generally easier to update database entries, compared to the process of fixing code and deploying the solution.  This is why dynamic configuration is often moved into the database.

    The Database can be updated in a variety of ways:

    • File drops – updating settings and the database through uploading files
    • HTTP endpoints – these endpoints can be called by another system or by developers to change the behaviour of the system.
    •  Remote app configuration – allow certain settings to read from a remote source such as Azure App Configuration
    • Creating SQL lookups and/or configurable fields that can be updated directly

    It is often the case that a large amount of code infrastructure will be required to make items configurable. It, therefore, makes sense to choose wisely which settings, rules and/or fields need to be changed on the fly.

    • Shortlist and prioritise the settings that will be changed often
    • Plan a mechanism so that it can be reused for other settings
    • Estimate the work involved to make the code configurable and allow code reuse of the configuration mechanism
    • Implement a solution that will allow for dynamic configuration

    Conclusion

    When it comes to coding, we love over-engineering. We also love making systems dynamically configurable.

    This allows systems to stay online while we change settings and rules.

    It makes sense if the trade-off with the time of implementation is justified.

    Sources consulted

  • The Effectify Way – Planning your software development project

    The Effectify Way – Planning your software development project

    Effectivity through good processes

    Every day many employees and businesses use complexity as a way to hide issues and unprofitability. .

    One should never be dazzled by complexity.

    The Effectify way is, as the name suggests taken from the Toyota way. It’s about optimising the process and simplifying what we have to have better performance and make something more usable.

    Our approach

    The SDLC and problem solving

    Though the software development life cycle is cyclical, it very often happens that the clients prefer to hand over the maintenance of the solution to their own team or hire their own software developer to maintain it.

    For this reason, the process below is linear.

    The Effectify Way focuses on solving customer issues.

    Once a problem is defined, it’s only a matter of time until it is resolved.

    As it’s important to find, define and solve the problems long before the coding starts, the focus is placed on research and understanding the problems involved.

    What if the uncertainty is too great?

    In certain scenarios, a problem cannot be defined as easily as the above. For example, a startup functions under extreme uncertainty.

    Though many problems can be solved, one needs to solve only relevant problems. This needs to happen in bite-sized chunks.

    As the answer to the current problem could determine the next question/problem to solve, it makes sense that a linear approach would be unproductive. A cyclical approach would be appropriate for businesses that have a high level of uncertainty.

    Each iteration identifies the next question that needs to be asked. Once the question is identified, one can execute a test to receive the next answer.

    Should my project be linear or cyclical?

    Depending on the client needs, either one of the two approaches can be used.

    To avoid the deadly spiral of over-engineering, it is wise to use certainty as the gauge for the decision.

    Once the diagnostic phase has been completed, the appropriate approach would surface.

    The diagnostic phase

    Before any coding or work starts, we prefer doing a diagnostic phase.

    It’s important that we understand the problem that we need to solve.

    For example, a client is looking for API integration with all the major phone networks. He hasn’t inquired yet about existing APIs and current functionality. If this is part of the core functionality, this dependency could determine the success of the project. It would be irresponsible to give time and monetary estimates unless this has been unpacked.

    It’s definitely not ideal to start a project and halfway into the project it is discovered that the timeline moves out with 6 months, or that the vital integrations do not exist.

    Research and planning

    Once the diagnostic phase has been completed, one is able to give timelines and cost estimates for the work that needs to get done.

    Once the research and planning phase has been completed, a research document – a business requirement specification (BRS) will be delivered to the client. This is very similar to a business requirement specification, and developers can use this as a base for the coding that needs to be done.

    In the diagnostic phase, the technical aspects such as API integration, third party requirements and the appropriate platform has been fleshed out. In the research and planning phase, the appropriate system and code architecture needs to be considered.

    The research and planning toolbox

    Technical and code approaches
    • Appropriate technology choices
    • Architecture choices
    User Experience
    • Personas
    • Needs analysis
    • Process flows
    • User stories
    User Interfaces
    • Corporate identity and branding
    • Low fidelity mock-ups
    • High fidelity mock-ups
    • Icons

    In the research and planning phase, the user experience research and user interfaces are also included.

    To understand the user better, the Effectify way does a needs analysis (which could take the form of interviews, data tracking and collection of relevant information). From the information gathered, personas are created, followed by process flows and user stories.

    Execution – coding the solution

    Once the blueprint is in place, the execution can start. The blueprint will dictate the following:

    • the technology used – including coding framework, language and architecture
    • the platform (mobile, web, desktop application, cloud, etc)
    • third party integrations and external technologies leveraged

    We believe in a UI first approach to get more client feedback earlier in the software development lifecycle. If one can see how a solution will look and navigate, the code logic can be set up accordingly.

    It’s also important to supply weekly updates so that no one is out of the loop about where the project is and where it’s heading.

    Testing and feedback

    It’s worth noting that any company that claims that they write bug-free code needs to be avoided. As humans are involved, bugs are bound to creep in. For this reason, the Effectify Way avoids the ‘big reveal’ at all costs and does small incremental releases so that testing starts early in the process.

    Though unit test coverage for code is vital for code stability and trust, it’s also important to do negative and functional testing.

    Conclusion

    The Effectify Way is about simplifying processes.

    When someone uses software written by a developer, it needs to work.

    More importantly it needs to be used – it needs to be relevant, easy to use and viable.

    Simply put, it needs to be effective.

  • Small business: pricing and costing services and products

    Small business: pricing and costing services and products

    The price needs to be right

    Facebook decided early on that they will be giving away their product for free. They will gain momentum by leveraging economies of scale to grow fast. Once they reached a sizable user base, they started to monetise the platform.

    An early decision of charging a fee might’ve dealt a defeating blow in the early years of the company.

    Today, more than ever, it is becoming more important to price your product or services correctly, as your company health (and your livelihood) might depend on it.

    Negotiating price

    All clients have a budget in mind – even if it is on a subconscious level. The number they have in their mind’s eye is of what the deliverable is worth, the market value and/or how much money they are willing to spend.

    No client has an endless supply of cash from which they can draw from.

    It’s therefore important to know early on in a project what the budget it and what you would need to deliver within the parameters.

    As a professional, it’s important to talk about money early on in the conversation. Your time is valuable and you don’t want to waste their time either.

    When the time is right (as early as you can), start talking about costing and financials. One might argue that the customer needs to be eased into the talk, yet we need to realise that we are sacrificing our time that could be used to find other clients.

    Have the tough conversations early on in the relationship.

    Costing models

    There are many models that business owners use to decide on pricing and costing. Many PhD’s have been done on the matter, but for this article, let’s simplify the models. Here are some examples:

    • Cost-plus: Adding an amount or percentage above your base costs. For example, if you hire a developer who charges per project, add a percentage on top of that for your profit.
    • Competitors’ pricing: Some services require an analysis of what the market is willing to pay for something. For example, the going rate for a 3-star guest house in a certain area has a range of what can be charged.
    •  Perceived value: A customer has a perceived value of what you’re offering them. For example, a developer wrote a code library for machine learning. Even though this might be simple to implement, there is a perceived value that will be added to the purchaser.

    Costing for services

    There are generally two ways of pricing a service: an hourly rate or a project-based rate. For freelancers, this is challenge, whereas for established businesses it is taken in their stride – the experience with clients pays off!

    With the above models, we can get an idea of what to charge. Here are some examples:

    • A customer requires project management and software developers for his project.
      • The software developers quote you a project fee to complete the solution.
      • The cost-plus model can be used to add a markup on the work of the developers
    • A customer requires a software solution that has a business requirement specification in place already for a document management solution.
      • for longer-term contracts, the developer can charge an hourly rate that is in line with the current market conditions.
      • He can also charge an extra fee on top of this rate for specialising in the above field, and because he adds more value than just coding.

    Complex services pricing scenarios

    Some scenarios are more complex.

    Take for example a startup that is looking for a software developer to develop their product or someone looking for an eCommerce site that looks like their competition’s.

    In such scenarios, it’s vital to understand the scope of work that needs to be done. A business requirement specification needs to be in place with the full scope of work to protect the small business from over-investing their time and money into making a project work for a client – at the cost of their business.

    Scope and pricing

    In some industries, it might be necessary to have a diagnostic phase where a proper scoping of the problem that needs to be solved can be achieved. In software development and design, the scope of a solution needs to be defined on a per-client basis, as each has unique requirements.

    As a deliverable of the diagnostic phase, a business requirement specification (BRS) should be issued to the client.

    Pricing a product

    Costing products tends to use the cost-plus model. This will ensure that the product is not sold at a loss. In some cases, there are scenarios where the pricing is not that straight forward. Examples of these include:

    • Software as a service (SAAS): A monthly charge to use an online service
      • The cost-plus model can be used to determine the running costs.
      • The value the service adds to the client’s business determines if a premium can be charged.
    • A code library is sold that enables file format conversions.
      • A competitor analysis can be done to determine the going rate of the service.

    Conclusion

    Pricing a product or service is not easy. In many cases, in-depth research and a business requirement specification is required to give an accurate estimation of the work required.

    Do not quote in haste, as you will be bound by it.

    Happy simplifying.

    Sources