I am an engineer. At least that is how I think of what I do.
Being an engineer is to label myself as someone who goes beyond just writing software. It tells those around me that I focus on skills outside that of a traditional developer. As I practise my craft, I focus on ensuring that the applications that I create are effeciently scoped, estimated, documented and built with maintainability in mind. This is an important and often overlooked aspect of software creation. I want to outline why and how I perform these activities.
In my current role, the projects that I work on are short - often no more than 2-6 weeks in length. That involves back and forth with clients, development of content and integration of feedback. Setting the correct scope, and therefore expectations is of the utmost importance. Incorrect scoping can get you into situations were delivery of the end product is late, overbudget or both.
The way that I approach this is to understand what is being asked of me, the team and the output. Listening is the first step; letting others get everything out in the open. Next, I like to go through a small state management excersise, looking at complexity. A large application thats just lots of the same is different to a small application that is highly conditional or changing.
Next comes the hard question, timeframe and budget discussions. Without having a clear understanding about what you're prepared to pay, you're going to hit the client with a quote/bill thats completely different from what they expect. Once you have all three of these things you can set the scope of a project correctly.
Once you have scope, Estimation comes from experience and proper plannning. My process involves mapping out the feature set, linking each feature together with its interdependencies (how are features connected).
The process of documentation is intertwinned with development. When I first started programming, documentation was always an after thought. The why was
Something always goes wrong or changes. New information comes along, clients change their mind on a feature, or you hit a roadblock that just grinds a project to a halt. How you plan for that eventuality is the mark of an engineer. My experience so far indicates that there is no half backup plan, you are either flexible to change or your not.
I'm going to keep doing what I am doing; but never one to stand still I intend to keep pushing the boundaries of what is possible. Working in the software development industry can be frustrating when those around you want to skip all these "unnecessary" parts and just end up with working code. In the long run however, its these skills that make life just that little bit more predictable.