June 19, 2015

...Learn TDD with Codemanship

A 'Software Developer' Knows Enough To Deliver Working Software Alone, And In Teams

A long discussion on a telephone conference this morning ensued about what a "software developer" is.

This relates to education and apprenticeships. They're an SME contemplating running an apprenticeship scheme, and - having roundly rejected all the officially government-snactioned schemes out there as being 'too business IT orientated' and just a bit too general and handwavy for their needs - they're naturally asking the question: what should a software developer know how to do?

We harked back to Scott Ambler's idea of developers as "generalising specialists". Perhaps, we argued, a software developer is someone who is capable of doing all of it - managing the work, gathering requirements, designing and architecting solutions (including a basically good enough user experience), implementing code that satisfies the requirements and is reliable and maintainable and scalable and fungible and edible etc enough for the customer's needs, testing it thoroughly enough to make sure of that, releasing or deploying it into the working environment, and maintaining it over many future releases - to a basic level of competence.

In short, a "software developer" might be someone who would be capable, just working by themselves and directly with the customer, of delivering working software that has value to that customer.

Having said that, we also recognised that working in teams brought its own set of concerns and challenges, and requires more skills than does working alone. And so, we also speculated that a "software developer" is someone who not only can deliver working software alone, but they can also successfully deliver working software as part of a team.

This is actually giving us a good steer on what the basics might need to cover. You wouldn't, for example, be able to get away with skipping build automation in your apprenticeships, because that's a necessary part of delivering working software, and by this definition, something every software developer should know how to do.

Nor would we be able to get away with skipping Continuous Integration in their practical education, because that is a necessary part of working in teams on the same piece of software.

And so on.

The long and the short of it is that a "software developer" needs to know the basics of all of the key development disciplines - including how to manage it - to satisfy our definition. They would not, for example, be clueless about software architecture, because there may be no architect to tell them what to do. They would not be able to rely on testers, because they may be the only tester - aside from the customer, of course. They would not be able to count on the services of someone from IT operations to build and configure machines, networks and all that malarkey, because they may be the only technical person involved.

And so on and so on.

Now, I'm not suggesting that every developer has to be a world-class expert on all of the disciplines. A strong command of programming, with a practical appreciation of how to do the others - practical enough to do a basically good job yourself - would suffice.

And, yes, that was our third and final idea: a software developer is first and foremost a programmer, and that's simply because - if working software is the desired end result - then all roads lead to code.

The thinking continues...







Posted 2 years, 7 months ago on June 19, 2015