After seeing how the medical community trains doctors, I wonder if something similar would work for software as well. Send "engineers on training" for 4-6 week stints in various "specialties". So you'll be desktop support, then a DBA, then a java programmer, then you're doing .Net, then QA, then you're PM'ing a project, ...
Do that for 2-5 years and expect people to get up speed in almost no time. How would that go? They do that with people's health (properly supervised and with slowly increasing responsibilities), why can't they do it with software?
By expecting people to get up to speed right away, I think that a lot of unnecessary process would quickly be cut out and best practices would quickly "cross-pollinate" across different sub-fields of software development. Best of all, people would understand the pain that other groups suffer because of actions done in other groups.
We've talked for a couple of years about rotating a developer into the maintenance group for a 3 month stint so we can fix the issues that cause pain over the course of the life of a project. I don't know if that will happen, but I think that it would be good to be able to see the side of things from different viewpoints. At the very least I think that it would foster better relations between groups.
I just think that by having people work in all of the different phases of a project and groups in an organization would help people see things from a system perspective. It's all about the big picture.
I think it would definitely be a good thing if software engineers had a more defined path on how to get to be a software engineer. From what I've seen on Grey's Anatomy (which is completely accurate to how things work in real life, just like CSI), becoming a doctor is a lot more defined. You go to school for a bunch of years, then you do your internship, then your residency, and then you actually get to be a real doctor. So you don't get to be a doctor until you've done like 5 years of on the job training. And as you do this training, you're actually on the path to becoming a doctor.
ReplyDeleteHowever software doesn't work this way. With software development, you do 4 years of school, if you're lucky, with co-op, and then you're shoved out into the work force and you fend for yourself. No more training or testing. The only learning you do is what you can pick up on the job, and the only tests are ones you write yourself. You don't know if you're even headed on the right track to becoming a software engineer,
I think it's important to have an idea of how aspects of software development operate. This gives the developer the ability to think about how their choices affect the entire process. Low level programming, high level programming, CRUD programming, UI design , testing, maintenance, systems/DB administration, are all very important. And a good developer should know a good bit about all of them.
The best way to learn all of those aspects of software engineering is to do them on a real project, not sit in a classroom. Half of the things I learned in university were outdated or wrong because most professors don't write software that is used in production.
ReplyDeleteA lot of software teams seem too big, with jobs too specialized -- the trees can't see the forest because they don't understand what the other trees are doing. If you're working on a project by yourself or with 2 or 3 other people, you have to wear all of the hats and you feel all of the pain. There's more incentive to improve the process because you're impacted by all of it and not just a small slice. There's also more ability to change the process since fewer people need to reach consensus. Big teams aren't always needed to do big software projects.
"Software Engineering" is a new field. It could certainly learn things from other fields but it will take a long time until it gets to the point where civil engineering or medical practise are at now. Both of those fields have been around for hundreds, if not thousands of years.
Even after all of that time, a medical education and internship still doesn't seem all of that great for the prospective doctor's health -- what is that supposed to prove, that doctors have a sense of humour?
I agree that within a small project team you're more likely to be able to learn more and remove crap process. Most projects that I've worked on have been 2-3 developers max. But it sounds to me that you're only taking about software development, which is only one slice of the spectrum of IT. Being effective on 1 project doesn't mean you'll understand what it's like to manage a db cluster for 100+ applications.
ReplyDeleteI'm talking about end to end. The "IT" guys that keep the servers running smoothly should be first class citizens on a team too, with feedback into the process. The team will understand their problems because they can easily communicate with them. The IT staff shouldn't be sitting in a server room managing dozens of other projects with a work queue and a red telephone.
ReplyDeleteJim, that's very true about managing large IT systems -- but it does make me wonder why there's one cluster for 100+ applications. Talk about all of your eggs in one basket.
I'm not a fan of the centralized IT turf approach that big orgs like to take. The IT group ends up being too big and too far from the development and stakeholder needs and the developers end up too far from real world IT pragmatism.
Each group's tasks are so specialized that they can't relate well to each other. As the groups get larger and increase in quantity, the process to communicate between them becomes more formal and slow (bogged down). That slowness affects every other part of the development process. On top of that, every project has different IT needs.
That kind of separation demonstrates to me that the company is more serious about getting the IT right -- at the expense of the software doing its job effectively (the right features) for the stakeholders and being able to make changes the stakeholders need over the lifetime of the project (agility).
The Eclipse project is an example of a large and successful long term project inside a big org like IBM. Their team manages everything on their own end-to-end. They've been successful because they have autonomy.
What good is uptime if the project is a POS that doesn't help people effectively? It's the same thing as focusing too much on estimation and budgets.
Software Engineering needs to focus on project success: that the software actually helps people do things better. We don't need more focus on shipping the product, estimation, budget, schedule, task assignment or uptime. As an engineering discipline, we should be embarrassed that our failure rate is as high as it is. Success should be the number one thing a software process optimizes for, with those other factors (like uptime) being important but secondary.
...sorry for the rant :)
I've been re-reading these comments over the last couple of days to digest them. All very interesting.
ReplyDeleteRyan: you defined project success as "software [that] actually helps people do things better".
Since we're talking about engineering - which means your criteria should be measurable - how would you measure that you were helping people do things better?
I was going to suggest some ideas, but I don't want to pollute your definition. ;-P
How do you as a rails freelancer measure the success of the projects you work on?
(Note: I don't intend the tone for this to be challenging, I'm just curious)