As a follow up to the DDD Scotland open discussion session on Professional Software Development, this hangout was held to discuss the changes and challenges 2 years on. I’ve included a few notes below that made up the main talking points, and added links where appropriate for those looking for more information.
You can see my notes from the session on Google Docs : https://docs.google.com/document/d/1AbyvGJluSvndc7feAn_G0OhHpQ_W-F-y2zPXJpw2X2o/edit?usp=sharing
Or, for Evernote users : http://www.evernote.com/shard/s2/sh/f6df9b20-583b-4741-9387-68bd900e81d1/f96b05fd7285445eac2d51d2ca67cb7f
Don’t ask the customer what they want – what they need to solve their problem isn’t necessarily what they ask for. Why do they need it? When do they need it?
Tom Gilb methodology – don’t tell developers what you want, tell them what problem they have and what benefit it provides.
Enhancing professionalism of a team
Different levels of professionalism depending on the level of the team, enforce standards when teams are cowboys and relax them as people get more experienced.
How do you bring professionalism to the team or to new members? Provide information and guidance. Define new practices. Tools such as JIRA, use of source control, tie commits into tasks and issues.
Phases : in a small team, pick the right people, and they set the culture. For existing teams, need stronger sticks to enforce behaviour, technical. Role models, training and mentoring.
Public good : What is a universal public good? Depends on the country. Kill-bots are good for saving lives of US soldiers, but not so good for Afghanistan and Iraq citizens. Public interest disclosure – whistle-blowers. Responsible disclosure of exploits or data protection or other breaches. Do you close the hole first or notify first. Also thinking about data protection. Keep data in the right area to avoid DPA or Patriot Act breaches.
Don’t be evil. Don’t do anything illegal.
US has a very different concept of “professional” from state to state. More like the Electronic Engineer chartership – CPD, maintaining quality, providing guarantees.
Health and engineering, been around for centuries. Being responsible if things go wrong. “I’m certified in a few things, and I’ve decided I don’t like it very much”. Defines those “in” and “out”. See “scrum masters” – disbarring people who don’t do things the way things should be. See lawyers in US getting disbarred for opposing the Vietnam War.
Software Craftmanship – principles and practices, a set of standards we agree to adhere to.
Saying no – if we can’t meet a deadline, say so. If something takes too long, make impact on deadlines clear. If you’re dependent on other systems, you’re very sensitive to them, and you have to adapt to them saying no.
Chartership – does that give your argument more weight? Does it help to build trust with the client?
Not enough software developers! And a lot of them are contractors. Scouring the world for the best talent.
Finance doesn’t trust certain developers, particularly in other countries (outside EEA especially), but skills are improving everywhere.
No ego – being gentle when criticising, removing ownership from code – owned by the team. Shared code ownership.
If you can’t keep up with the latest technology, or other CPD requirements, then you’re in the wrong profession.
SEMAT- Ivar Jacobson (UML) : make a kernel of “what is true about software engineering” that no-one can dispute. Dictating a flow of information between customer and BA and between BA and developer.
12-14th April : Learner Journey Data Jam
19-21st April : Mental Wellness Hack Weekend