What should I give to a computer programmer?

Tools (what you should give your programmer)

A modern PC with enough RAM, compute power and local storage to build the software required with admin rights on the local machine. If the organization will allow it, get a budget of $1500-$2500 and allow the developer to spec the system needed. Software Developers are going to be putting in a lot more time behind a keyboard than an average user. They need hardware that’s built to last and not budget grade equipment. If you go the cheap route you’ll likely have down time due to hardware repairs which will cost you more. Not to mention programmer bench time while the repairs are being done which you’ll likely also pay for.

Ergonomic peripherals and furniture. Mice, track balls, mouse pads, keyboards, monitors, office chair, etc… should all be ergonomic. I can tell you when I’m working in a high quality office chair such as the Herman-Miller Aeron vs a $200 Office Max special, I tend to get much more work done hour by hour.

A fast, reliable Internet connection.

A productive office environment. For software developers studies have shown very negative impacts on productivity in trending open office environments. If your attitude is “that’s too bad, this is our corporate office vision” so be it but the reality is most programmers you put in an open office environment would be more productive in a more private setting. So your company’s decision to go with an open office layout is impacting your bottom line. If you can get upper management to agree to a work remote option at least a few days a week you can help prevent some of that loss. If you have a trust issue with a programmer working remotely then you either aren’t hiring the right people, don’t have the right feedback loops in place to effectively manage or you are a micromanaging control freak who should probably consider letting go a bit.

Management Practices & Methodology (what you can expect your programmers give back to you and how to maximize productivity)

This depends on the size of the company and type of software being developed. If it’s a large company creating Enterprise software, you will have business analyst helping drive the requirements. In smaller companies the owners will often be acting as the business analyst and perhaps this is your function.

Software is built following several methodologies but the most popular two approaches are a traditional waterfall methodology or an agile approach. There are volumes written on these two systems from documented use cases to theory. To give you both in a nutshell: Waterfall approach is traditional engineering. A rigid design spec usually spanning hundreds of pages filled with input-output flowcharts, user interface mock ups, module break downs, etc.. is put together and presented to the stake holders. A meeting is held explaining the document and it’s handed off for review. If this document is created internally then it could be shopped to outside contractors for bid proposals. If you’ve hired a consulting company then they would most likely provide this document to you and provide a cost estimate and present terms (fixed bid contract or time and materials contract with cap). Sign off happens, deadlines are set and construction begins. Three months into the project you begin to notice things that are desired but were left out of the design spec which you signed off on. These desired changes become Change Request which get amended to the document, push your deadlines further out and require more money to be spent by the development team to evaluate the impact your needed changes are going to have on the whole system. Things can get very expensive. Projects slated for nine months can go years in this never ending cycle until they are eventually canceled by upper management and then heads rolls.

To help mitigate these nightmares agile methodologies have risen up. With agile the idea is simple: build large projects as a collection of smaller parts. Make each part something that can be built over a series of sprints (a sprint in a unit of time, usually 1–2 weeks) and keep close monitor on the progress to insure the features the developer promised could be delivered within the sprint are being delivered. The last part is done through code review, frequent demos and requiring your programmers to apply unit test to their code. Unit testing frameworks have tools that non-developers can use verify that your developers aren’t introducing new bugs as they make changes.

Having been on hundreds of software development projects over the years I can tell you there are trade offs with both approaches. What your stakeholders/executive team want is for the project to consume as little of their time as possible and have the least amount of risk, but that dream scenario really comes with balance that’s hard to achieve. For Agile methodology to work well, stakeholders have to be actively involved in the feed back loop that the Sprints provide or they must have managers running these meetings who have a very deep understanding of what is desired at a high level who are able to pull the brake and pivot when things start to go bad. You also need a manager who is technical enough to guide your developers in breaking their work up into task that fit into sprints. Unless you have full time commitment from the stakeholders and competent management and developers to keep the wheels moving, Agile methodology can be even a bigger train wreck than Waterfall.

If you hired a few contractors and held a few meeting detailing a spec, don’t expect them to self-organize and deliver a methodology. For all but the smallest projects you need someone devoted at least part time to managing things. It’s not just insuring the developers are producing code instead of playing World of Warcraft, it’s more about making sure that most lines of code your developers are writing are progressing the project forward and are aligned with the stake holder/project owners vision. People are generally horrible at detailing exactly what they envision in their head and what they initially envision could almost always be improved upon through the input once parts of the system are available to interact with. This is sort of the core tenet of Agile: incremental delivery over short iterative cycles understanding each sprint could lead to discoveries that take the development down a slightly different path.