I have been slightly freaked out recently by the extremely positive feedback I've been getting around a project I've been working on that is based heavily on an open source solution.
I've been down the open source path many times before - almost exclusively as a consumer or indirect contributor (offering suggestions to the project owners) - but not as a contributor with a major enhancement, say. It's just never happened. Most open source "does enough" for what I want to do as is.
At first I was intrigued that my manager showed such excitement that I could take something effectively free & get it to a point where it was actually useful for the project. As I said, I've used enough projects before to expect a non-perfect solution, but usually something viable comes up.
Then, she started getting excited with the idea of me sharing my experiences with other teams to encourage them to think in terms of not just using open source, but doing so with the intention of contributing back to those projects from the outset.
Again, not that radical from my perspective ... until she explained that the company - a financial services giant in the market - never thinks of open source as an option, let alone thinks of being a part of the community of dedicated IT professionals who spend their spare time, or else contribute from their company's development time, to make stuff for other people to just find & use as they see fit.
Admittedly, there are two very different software worlds out there - vendor world, & open source world (plus some blurry bits in the middle). Those two worlds only differ in their attitude towards licensing, not in their attitude towards quality.
In fact, there is a massive industry out there effectively being the consulting services, bespoke development or customisation, or support arms of open source projects. These people are an important part of that open source community because they get direct customer feedback on what makes better product (as opposed what sells better). They drive the development in the same way that vendor product is developed from marketing strategy & product leadership.
Yet many service sectors that rely on IT professionals to provide infrastructure (in financial services, telecoms, utilities) "feel more secure" out-housing the mitigation of their technology risk to the very people providing the technology, that is, through licensing & maintenance agreements.
Once upon a time, banks in particular used to have massive in-house development creating bespoke solutions that worked exactly the way they needed. That's out of favour. What's in favour is getting in the same consultants as the competition did to build something sufficiently different .
I know that my company is not one-hundred-per-cent happy with that arrangement. Very few companies are. I can name very few enterprise solutions that "just work" to the point that you can believe the marketing hype.
So, now's the chance to try something different. Start small & look to see if there is a way to introduce open source solutions into a project - cost it out in terms of support. If that works for you, try enhancing an open source project & contributing to the open source community to become an influencer of the development of such solutions, rather than just a consumer.
The "cost" of transforming thinking may be less than you think. The benefits may be more than simply financial. The end goal is to be able to provide a better service to your customers by owning more of the knowledge around the service & being able to make your service better under your own control.
Saturday, April 30, 2016
Saturday, April 23, 2016
Mind Your Language
I don't like admitting this, but I feel I've cheated on a recruitment test.
A while back, I was interviewed for a role with a company that worked predominantly with NodeJS. I told them I was a novice, & they said that was OK, because they needed someone who could do some project management work, & I had that experience.
Then they asked me to do their NodeJS test. They said I shouldn't spend more than, say, four hours on it.
I learnt enough NodeJS, & a few other bits of infrastructure I'd never heard of, & produced a competent solution for their test - all in under four hours. I even specifically left out the enhancements that I'd thought of for testability & stability, on the basis that I didn't want to press my luck.
To me, NodeJs is still just javascript. It's no silver bullet.
Two things about the situation have worried me since:
I am a Java dev. I can do lots of other things, but Java's been my core language for fifteen years. I've learnt the new features as they've come on board. I've been exposed to a lot of libraries, frameworks, & open source solutions over the years that have allowed me to develop things a lot faster than I used to, because I can leverage the experience of others' in the community.
I am aware that you can probably do the same things in C#/.Net for the same reasons, but have no interest in doing the same things in a different way if they achieve similar results.
What worries me is when someone specifically tries to do one thing in a different way because it's "too hard" to learn how to do it in the current way. If you look at NodeJS as nothing more than a few short-cuts in (server-side) Javascript, then it's really a technology that saves time & effort for a few mundane tasks. Excellent. Move on.
If you think of NodeJs as a revolution because it makes it easy to do those mundane tasks, then you've missed the point of software development in general. NodeJS is a triumph of software development, not a panacea for it. The people who developed it are craftsmen who knew their language (Javascript) & used a lot of experience & skills to solve real world problems in their community.
Only the marketing folk believes that NodeJS solves the problem of world hunger.
A good javascript dev now breathes a sigh of relief when they have to do that boilerplate for web services. A bad javascript dev (or a NodeJS dev qualifying after four hours) thinks that they are God's gift to the software industry because they can replicate some googled examples.
Whatever programming language you develop in, if you learnt it in a matter of days - or even weeks - then you cannot possibly understand why it's useful, or in what context it should be used. Even after you know the limitations, you need to learn how best to use the programming language - through patterns, best practices, software architecture, design, testing, etc.
This is not something you can learn on your own - ever. It is certainly not learnt in a short amount of time. It comes from a lot of commercial experience (where other people are your customer) & teamwork (where other professionals give you feedback).
If you can acquire "skills" that can be learnt sufficiently to pass a test within hours, then why aren't employers taking some responsibility for that training - offering guidance, mentoring, etc - to ensure that the skills proliferate within an organisation, & to encourage learning in the workplace?
If companies appreciate fine craftsmanship in their software deliverables, then why don't they encourage an environment that fosters improving the skills of the developers to make them better at what they were hired to do?
Although all developers should find out about new technologies & play around & learn constantly, they should also learn more about their craft & the technologies that they already claim to be familiar with, with the hope that they will get better, help others to become better, & contribute to the betterment of their organisation.
A while back, I was interviewed for a role with a company that worked predominantly with NodeJS. I told them I was a novice, & they said that was OK, because they needed someone who could do some project management work, & I had that experience.
Then they asked me to do their NodeJS test. They said I shouldn't spend more than, say, four hours on it.
I learnt enough NodeJS, & a few other bits of infrastructure I'd never heard of, & produced a competent solution for their test - all in under four hours. I even specifically left out the enhancements that I'd thought of for testability & stability, on the basis that I didn't want to press my luck.
To me, NodeJs is still just javascript. It's no silver bullet.
Two things about the situation have worried me since:
- why test someone's competence in a technology that they can learn from scratch in a few hours?
- why insist on recruiting for that skill if you can train someone in a few hours?
I am a Java dev. I can do lots of other things, but Java's been my core language for fifteen years. I've learnt the new features as they've come on board. I've been exposed to a lot of libraries, frameworks, & open source solutions over the years that have allowed me to develop things a lot faster than I used to, because I can leverage the experience of others' in the community.
I am aware that you can probably do the same things in C#/.Net for the same reasons, but have no interest in doing the same things in a different way if they achieve similar results.
What worries me is when someone specifically tries to do one thing in a different way because it's "too hard" to learn how to do it in the current way. If you look at NodeJS as nothing more than a few short-cuts in (server-side) Javascript, then it's really a technology that saves time & effort for a few mundane tasks. Excellent. Move on.
If you think of NodeJs as a revolution because it makes it easy to do those mundane tasks, then you've missed the point of software development in general. NodeJS is a triumph of software development, not a panacea for it. The people who developed it are craftsmen who knew their language (Javascript) & used a lot of experience & skills to solve real world problems in their community.
Only the marketing folk believes that NodeJS solves the problem of world hunger.
A good javascript dev now breathes a sigh of relief when they have to do that boilerplate for web services. A bad javascript dev (or a NodeJS dev qualifying after four hours) thinks that they are God's gift to the software industry because they can replicate some googled examples.
Whatever programming language you develop in, if you learnt it in a matter of days - or even weeks - then you cannot possibly understand why it's useful, or in what context it should be used. Even after you know the limitations, you need to learn how best to use the programming language - through patterns, best practices, software architecture, design, testing, etc.
This is not something you can learn on your own - ever. It is certainly not learnt in a short amount of time. It comes from a lot of commercial experience (where other people are your customer) & teamwork (where other professionals give you feedback).
If you can acquire "skills" that can be learnt sufficiently to pass a test within hours, then why aren't employers taking some responsibility for that training - offering guidance, mentoring, etc - to ensure that the skills proliferate within an organisation, & to encourage learning in the workplace?
If companies appreciate fine craftsmanship in their software deliverables, then why don't they encourage an environment that fosters improving the skills of the developers to make them better at what they were hired to do?
Although all developers should find out about new technologies & play around & learn constantly, they should also learn more about their craft & the technologies that they already claim to be familiar with, with the hope that they will get better, help others to become better, & contribute to the betterment of their organisation.
Friday, April 15, 2016
Death to Project Managers
Can you imagine a world where a killer virus transmitted through Gantt charts wiped out the population of project managers? How would anything get done?
The short answer is - "by doing things differently" ... & "no".
But bear with me for a few paragraphs. Taking a leaf out of an old Edward de Bono book, simply imagine that project management as we know it is impossible & we have to find another way to get things done that does not involve the skills & techniques that we currently use.
If we had to reinvent the process, would it come out the same?
We don't have to reinvent. In fact, I've worked for several companies that don't have project managers - or they have one who doesn't get involved in projects directly.
Most variations on the Agile development methodology have no room for project management as such, because teams are self-directed.
You can see project management as a top-down approach to achieving a goal. It's quite traditional. Agile is always bottom-up. There's an assumption that the professionals doing the work know more than management about how to deliver the outcome - as long as they are empowered to make decisions & effect them, & have access to the information they need.
Admittedly, agile works best in small teams, but there have been many examples of teams of teams (layers of self-organising) where a team representative is the conduit to a higher level of abstraction. Certainly, if that higher level is concerned with business strategy, for example, then its membership is made of team leaders - those who can ensure the smooth working of the development team.
In this structure, project managers are not appointed to a project. Teams are assigned a business outcome. In some cases, teams own a product or a service, & their output is a part of the overall enterprise's offering - a direct contribution to the business' viability.
The alternative to project management is product management - not someone to ensure that deadlines are met, or to negotiate budgets; but someone to ensure that quality is defined relative to the business needs (usually associated with what an end-user expects), & can understand & articulate the requirements to the team & to management (to justify investment of time & materials).
Project managers have budgets. Product managers seek investment.
Product managers are invested in the product - the outcome - as is the team. Their passion is what drives the business' value proposition to their customers & investors in turn.
We can survive without project managers. For how long can a business survive without product managers?
The short answer is - "by doing things differently" ... & "no".
But bear with me for a few paragraphs. Taking a leaf out of an old Edward de Bono book, simply imagine that project management as we know it is impossible & we have to find another way to get things done that does not involve the skills & techniques that we currently use.
If we had to reinvent the process, would it come out the same?
We don't have to reinvent. In fact, I've worked for several companies that don't have project managers - or they have one who doesn't get involved in projects directly.
Most variations on the Agile development methodology have no room for project management as such, because teams are self-directed.
You can see project management as a top-down approach to achieving a goal. It's quite traditional. Agile is always bottom-up. There's an assumption that the professionals doing the work know more than management about how to deliver the outcome - as long as they are empowered to make decisions & effect them, & have access to the information they need.
Admittedly, agile works best in small teams, but there have been many examples of teams of teams (layers of self-organising) where a team representative is the conduit to a higher level of abstraction. Certainly, if that higher level is concerned with business strategy, for example, then its membership is made of team leaders - those who can ensure the smooth working of the development team.
In this structure, project managers are not appointed to a project. Teams are assigned a business outcome. In some cases, teams own a product or a service, & their output is a part of the overall enterprise's offering - a direct contribution to the business' viability.
The alternative to project management is product management - not someone to ensure that deadlines are met, or to negotiate budgets; but someone to ensure that quality is defined relative to the business needs (usually associated with what an end-user expects), & can understand & articulate the requirements to the team & to management (to justify investment of time & materials).
Project managers have budgets. Product managers seek investment.
Product managers are invested in the product - the outcome - as is the team. Their passion is what drives the business' value proposition to their customers & investors in turn.
We can survive without project managers. For how long can a business survive without product managers?
Subscribe to:
Posts (Atom)