Unfortunately, some still think that they can treat software engineering as any other type of work. Maybe it’s convenient, but it just doesn’t work. Here’s are two quotes I’ve overheard during just last week … :
"Scrum is awesome, it works really well if applied properly. And what’s even better, you can apply it wherever you want - it works well not only for software development. It works for everything.”
Le bullshit,
Scrum isn’t just about splitting the project into prioritized backlogs of items to do. It’s also about:
- delivering value as frequently as it possible (keeping in mind the constraints)
- focusing on what’s the most critical (brings the greatest value) and not analyzing everything up-front
- agreeing on first versions not being perfect (but still bringing up value), because of continuous learning and improving in future
- responding to change as a way to keep the software on par with ever-changing business reality
Aren’t those points contradictory to areas of engineering, art and zillions of other activities that:
- are far more material (substantial) and can’t be re-shaped as easily as software? (try refactoring the ship in the dockyard)
- can’t have early / partial version release, because they bring value only when complete (try release’ing 2nd version of movie)
- can’t be improved once they are released to the client (try improving the "good enough" furniture)
- can’t have the requirements changing constantly, because every change may invalidate whole endeavor (try responding to change while building a bridge)
Software engineering is VERY special. Some points in Agile Manifesto are truly universal and they can be used wherever you want (like customer collaboration or continuous attention to technical excellence) but some of them are real show-stoppers for typical work (even other types of engineering) and without them it’s not Agile anymore.
"We need programmers. Experience requirements: 5 yrs with ASP.NET MVC, 7 yrs with ADO.NET, 9 yrs with Fancy-Shmancy-Frameworkey."
Recruiters just don’t understand that there’s no guarantee there is any difference in ASP.NET MVC proficiency between people who accordingly: have 6 months and have 4 years of practical experience with MVC. None. Null. Zero. Why? Let me state it as briefly as possible:
- If someone didn’t learn the tech (keeping in mind the reasonable granularity, so don’t try that on .NET as whole) in 6 months, he won’t learn more in 4 years anyway. Half a year is enough to learn any tech, of course if individual is both willing and capable of learning it.
- If someone uses the same tech for 4 years, same scenarios, same type of work, same type of project - he *really* does not improve. In this case I’d prefer him switching every 6 months, so he’s more versatile and has “broader perspective”. Doing 500 views while following the same “recipe” won’t make anyone better (at least not in programming …).
To evaluate how good programmer actually is, you have to keep in mind that
- instead of overall work experience length you look only at the time he spent on doing new stuff (in other words - learning)
- tech / technique not used for longer than 1.5-2 yrs requires refreshment; longer than 3 yrs requires re-learning
- tech / technique older than 5 yrs is irrelevant (deprecated) anyway and has no real meaning
- theoretical knowledge without any practice is worth about 20% of practical experience
- the rules above do not apply for closed / legacy technologies (where any experts are hardly available and there’s no need to update as nothing changes through the years)
- in the end - no-one knows every possible tech, so the key point is that the particular person should be both a fast learner and have a software engineer’s common sense
Yes, it is significantly different to other types of jobs and this means that software engineers should NOT have a typical career progression path ruled by straightforward “years to rank” function.