“The one absolutely solid place to store your capital today — if you know how to do it – is in software developers’ wallets.”
...is what Venkatesh Rao states in his thought provoking article “The Rise in Developeronomics” published Dec 5, 2011 on Forbes. He argues that the future of our economy will be heavily dependent upon access to software development services as starting, growing, and running your business is bound to involve software nowadays. So he makes the case that the best friend to have to face these challenges is... a software developer.
I did not come to this industry with a software background. I studied math, physics, business, then finance. But over the past 12 years or so, I have learned quite a bit about how to pick a software... “friend”. So let me share with you 8 things I would want to know if I was starting afresh.
I would ask about the development process. I seem to take it for granted that all software shops operate on some type of “Agile” development methodology. The reality is much different. Beware of a once favorite software development process named the “Waterfall Model”, a sequential model in which steps are completed one after the other. First the customer would specify ALL requirements, then the app would be designed and coded, then -- and lots of time is elapsing here as you’d progress thru the steps -- it would be tested; then deployed. The drawbacks of this process is that it’s lengthy, unresponsive to change and yes, super costly. So the process you want your software friend to abide by is an Agile one. Because an Agile process calls for short development “iterations”, you get value in short increments of time. In a nutshell, it’s a collaborative process that delivers quickly and enables you to adapt to change.
I would ask about the development practices. Just like you would expect of your accountant to abide by certain Generally Accepted Accounting Principles, you ought to expect that your software “friend” abide by the following practices.
- The first one on my list would be TDD: Test Driven Development. No later than yesterday, I produced a spreadsheet that summarizes how an amount of money gets allocated amongst different accounts. In doing so, one could easily forget to include a cell. To put TDD in perspective to the non developer, my test to avoid such a situation would be to have a cell in which the formula tests that the sum of the parts would equal the whole, before even starting the allocation. A good software friend practices that as a reflex. Before writing any code, he or she writes tests to ensure that the code to be written will produce the desired outcome.
- The second one would be pair programming. If you have ever looked even remotely at code, it’s a lot of text. To me it may be mostly gibberish, but it does not take much convincing to understand that two sets of eyes are better than one. So hopefully, your friend has a friend, because, that will ensure less bugs.
- The third one is those short iterations we talked about earlier.
- The fourth one is continuous integration. This means that your friend is diligent about integrating to the rest of the system as a whole. It ensures that everybody’s work works together.
I would ask how my potential software “friend” would keep his or hers claws sharp. Again, just as you would expect your accountant to be aware of the changes in tax laws, you should expect your software friend to be aware of the changes in the software industry. My software friends usually go to conferences, read books, reflect on their work whether through blogging or presenting to others, and meet with other fellows in the field. They know several languages and work across multiple platforms. Better yet, they fear not learning a new one. Above all, they are far from being the stereotypical isolated geek one could envision.
I would ask for proof of talent. Although a degree from an ivy league university might do the trick for some, quality experience does set the good developer apart. My developer friends have loads to show to testify for their talent. For some, from past work done, for others, from apprenticeship projects, but for all, from hands on development.
I would ask about how they estimate. Systems built nowadays have variable scope. As a result, it can be difficult to estimate how long the project will take. However, I would advise you to befriend a developer that gives you a reasonable estimate. An estimate that could provide you with a bracket of possible values: one pessimistic, one optimistic, and one realistic. I may even push it to ask with what confidence do past project estimations fall within a 95% accuracy within the aforementioned brackets.
I would ask how deadlines are met. Deadlines are a critical variable for any business. If I were to befriend a software developer I would expect to hear that since the development process relies on short iterations and prioritization of requirements, I (the customer) hold the key to deadlines. I (the customer) would be the one prioritizing which features get attended first. I (the customer) would hence have control on where my ROI would come from.
I would ask about cost. Of the upmost importance, staying within one’s budget is a goal that short iterations can help to fulfill. When getting value in short iterations, cost is easy to tame. Prioritization ensures that the most financially critical decisions stay within the hands of the customer. A good software development friend will bill at a certain frequency of iteration completions.
I would ask about change. I would say to my potential friend: “How will my app be able to evolve overtime?” -- deeply concerned with the ever changing technologies, market requirements, and products I could offer. I would expect him to state that he values feedback and collaboration. A good software developer friend embraces change in requirements which are bound to happen overtime. Oh, and do I need to stress again that a good software friend develops in short iterations, which by itself, guarantees an adaptable progress?