I've worked on several software projects over the decades. Some well known. Here are a few of my views regarding software development, project management and workplace culture.
Software Schedules
Over the years I've worked on many large projects. I have come to the conclusion that projects beyond a certain size can not be scoped accurately when first conceived. This doesn't mean we shouldn't try. What it does mean is that a team and it's management needs to adopt an iterative system of some sort (like Agile) that allows for a gradual zeroing in on a completion spec and date. This also means that over time, tradeoffs need to be considered as the project progresses.The industry has long since learned that software development is unlike other undertakings due to it's incredible flexibility, diversity, and the fact that no two projects are alike. Tools have been developed over the decades to mitigate this. Processes as well. And for that matter, large construction projects are difficult to scope.
Management must be aware of this and account for it on the onset of any project. Management must buy into some sort of process where specifications and schedules are periodically revisited. That is the reality of software development and the tech world in general. Simply telling people to work harder and faster is never an acceptable game plan.
The Team
I can work alone in isolation on a part of a project, or on my own project. But I prefer working in an office with a team of others. I like to talk about code, learn about other's code and exchange ideas. I'm a very social person and enjoy being around people. I have many cube toys if that is appropriate to an environment. I also like people who have a healthy sense of humor.
While not a requirement, working classic science fiction and Monty Python themes into conversation is an added plus. :-)
Software Development vs Fixing Bugs
It's rare that a new team member enters a project where there is no existing codebase. New members are often tasked with fixing bugs as a part of the learning process. This makes sense. It helps the team and the new team member both. However, we all enjoy writing new code. We all enjoy ownership. We all enjoy design and development. In order for me to feel fulfilled, I must eventually create something of my own and be responsible for a significant part of a project. This creation can be something completely new, or a refactoring of something that exists.I like to build end products and development / qa tools as well (see Project Pluto for Openstack on my Projects page).
Process
I am somewhat skeptical of some of the more formal processes out there. Agile has it's place, but even popular literature on the subject sees this process as a pick and choose proposition. For some teams the daily scrum is useful. For others, meetings held less frequently work best. Sometimes formal backlogs are useful, whereas other teams can get by with simple JIRA task lists. However it's done, some kind of frequent team sync-up is useful. I find the daily scrum to be the best part of the Agile process.Test Driven Development is another popular methodology. But there's nothing new about TDD. A normal development process involves insuring testability of code as it's developed. The formality of writing a test before writing code is not an absolute. I often write the two at the same time. If anything, I'm a comment and micro-spec driven developer. Those are the things I most often write first. I do use unit tests to encapsulate and document model functionality.
In the end, the Ocham's Razor of process is to steer and lend predictability to a project, while taking as little time away from end tasks like development as possible. As such, process is always team specific.
Managing Expectations
Ideally, there should never be any surprises. Say what you're going to do and do what you say. In order to best accomplish this one should be conservative. Under commit and over deliver. I think we've all heard that a few times, but it makes sense.Tell people what is expected of them. Know what is expected of you. Leave as little to chance as possible. Crisp oral and written communication is a must. When things get touch, be open to tradeoffs. These are my thoughts both as manager and managee.
Judgment Calls
To a software developer, this can mean, for example, knowing when to and when not to code defensively. Teaching a user of your API that it's acceptable to pass bad parameters is likely the wrong call. Throw a descriptive exception. However in situations where backwards compatibility is required handling a bad parameter may be needed.When to pay down engineering debt vs. when to work with what you have is also interesting to think about.
All projects should be thought of as products, where some future you is the first customer.
These sorts of things are often the subject of great philosophical discussion.
Organization
Two words: make lists.Why do we write clean code with descriptive comments? We do it for ourselves. We will forget our train of thought six weeks from now.
Hit the Ground Running
Beyond the typical HR bringup, I'll need to know the basics. It's best to walk thru these things overtly in the beginning with other team members, rather than leave it up to the new guy to discover process over time. Some conbination of the two is often understandably the case as others are working their own deadlines.Fast bringup topics may include:
What are the build targets and what do they do?
Describe the development workflow. It's almost always unique to every project.
How is code tested in this framework? Are there unit tests?I often find myself asking these questions and end up being the person to document them on wiki pages for myself and others. You might have guessed by now that I'm a fiarily organized person. I can document both process and code.
(Few things are more frustrating than having a fuzzy sense of how the build system works.)
Softculture and Lifestyle
See chrishull.com
Every project teaches us how to do the next one better.