Showing all blogs in category Software Consultancy
August 29, 2018 | Software Consultancy
My last year or so here at OpenCredo has involved a very well-supported first foray into tech consultancy. Different engagements pose both unique, as well as familiar challenges for me as a consultant, all of which played a part in shaping and moulding the way I understand and approach problems. This blog is a brief collation of wisdom that’s helped me the most during this adventure; gained by learning the hard way, as well as that acquired from mentoring and colleagues who have gone before. The shared wisdom has made me a much more effective consultant, and kept me sane in the process, for which I’m very thankful.
July 13, 2018 | Software Consultancy
As a consultant I often find myself in situations that require tricky problem solving, typically of a technical nature. Yet although it is common to approach a consultancy engagement in terms of its technical context, not all problems have a purely technical solution.
February 28, 2017 | Software Consultancy
As Kotlin’s 1.1 release draws closer, I’ve been looking at some of the new language features it supports. Type aliases may seem like a relatively minor feature next to coroutines, but as I will show in this blog post, they can open up a new programming idiom, particularly when combined with extension functions.
January 13, 2017 | Software Consultancy
The notorious FizzBuzz interview test was originally proposed as a way of weeding out candidates for programming jobs who – to put it bluntly – couldn’t program. The task is as follows:
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
It turns out that this problem has just enough subtlety about it to cause headaches to anyone who knows the basics but hasn’t learned how to think in nested structures.
June 15, 2016 | Software Consultancy
It’s as simple as that – and as a consultant, it’s a problem I see all the time. Testing is always focused on functional testing. Non-functional testing, by comparison, is treated like a second class citizen. This means that functional requirements get refined, and non-functional requirements are ignored until the very end.
June 7, 2016 | Software Consultancy
In my previous blog post I explained to you the Seven Deadly Sins of Project Managers. With that post in mind, I would like to share with you my views on what a project manager needs to overcome these sins and become a valuable member of the team, and ultimately helping to achieve success on the project.
Good consulting is, by its nature, an act of collaboration. We recently helped a company with a variety of challenges – some architecture, some coding, some systems, some people, some process (normal consultancy challenges) – unique to this client. During the project, we formalised some things we had thought before, but which had never crystallised – all the work we did was transformative. Whether it’s a code review, process review, DevOps implementation, or outright transformation, the primary goal is the same – improving flow. Flow (sometimes known as throughput) is the movement of raw materials through a system to become finished goods. It’s analogy in the service industry is the movement of customer requirements through to usable solution. And we help improve it.
October 30, 2015 | Software Consultancy
Having completed my marathon 3-talks-in-one-day at JavaOne on Wednesday, I’m now in a position to share all of the slides and supporting material. First up is the content associated with my “Thinking Fast and Slow with Software Development” talk. I’ve already blogged about an earlier version of this presentation on the OpenCredo blog, and so won’t go into more detail here. However, I will include the video recording (thanks to the JavaOne team for this!), the latest version of the slides, and a much requested reading list!
October 7, 2015 | Software Consultancy
It’s well known that predicting how long a project/task will take in IT is hard. In this post I’ll address one aspect of this (correlation) and ask what insights a data science perspective can give us about how correlations can make prediction difficult. I’ll explain the problems that correlation poses, give some practical advice for teams & project managers and investigate possible innovations to tooling that might improve matters.
November 6, 2013 | Software Consultancy
In many organisations, development and test teams have a ready answer for this, and that answer is usually wrong. Commonly, teams use test counts and code coverage statistics, which alone are not enough to validate a test approach and run the risk of giving a false sense of security to stakeholders. In practice, we are not able to fully prove the efficacy of our test strategy until after a release. Once software is in use, new defects highlight where our tests are failing to validate the software and where we need to invest effort to improve coverage. This is where many teams fail to learn and improve.