You are blissfully removed from the reality of most large software projects.
What you describe only works under limited circumstances. Very few corporations will tolerate 40 releases in 5 years, let alone 1 year, they assume your product is unstable and requires too much monitoring and too many updates. You most likely are selling a product to other programmers.
How do you know you are building in quality? How do you know your unit tests are really covering real customer situations? What is the motivation for your average programmer to do any of this? Why put in the effort if management doesn't know the difference?
BTW - I agree with all your points, if we agree on what market you are in.
But - I seriously doubt that any programmer knows more about what the market needs, than any reasonably competent manager - if that isn't an oxymoron. I *have* worked with one or two reasonable managers in 35 years of doing this. Hell, I used to be one. At some point, you *have* to drink at least a tad of the kool-aid, from *someone*, just to stay sane and believe that you are contributing.
However, if your goal is to satisfy *yourself*, then all bets are off. In the world of business, that's absolutely the wrong goal.
Well no.
Decisions ARE made about the direction of the product.
But these are based on whatever is in management's face at the time, not on any actual
process of thinking or planning.
And then, the manager moves up, and the next manager wants to make an impact, so s/he changes the whole product direction based on the first thing s/he gets screamed at for not doing.
And of course, many products HAVE no meaningful lifetime, so why bother with much planning?
Just keep writing code, something good will happen.
So - agile sw happens because smart programmers know that management has no clue about requirements, so why waste time on requirements, just write some code?
There are a huge range of software products out there, one paradigm can't cover all needs. Of course, the biggest mistakes come from applying the wrong process to the wrong market need.
Anything that is intended to last more than 2 years will have substantial maintenance costs, but most managers move on after 2 years or less. No incentive to build it right, ever.
Most developers want to work on something new, leading edge, and they move on as soon as things go into maintenance mode.
It is far easier to react to customer complaints than to plan anything. The excuse is always that we have to keep the customer happy.
You will get crap from all sides.
You will be asked to compromise your personal views
in the interest of teamwork.
You will be ridiculed, screamed at, and a general target for anything that goes wrong.
You will be asked to deal with the most difficult engineers, and the most difficult customers.
If you are lucky, your own boss will watch out for you and only 50% of this crap will come your way.
Push back push back push back.
Protect yourself and your integrity or you won't get through it.
Having said all that, give yourself 18 months before deciding if you are cut out for management. Hopefully you will get a chance to manage 2 projects or 2 teams in that time.
I just stepped down from 4 years managing a data communications team that varied from 3 to 24 people. It started with 24 (bad start), a total disaster, and gradually got better and better.
Personal counseling helped a lot, a professional outside the work environment.
Last year my 4 best people were taken away, my schedule shortened and I was made responsible for worldwide product support - in the name of giving me a "chance to grow". I quit when it was clear that my bosses would not budge on anything, and didn't really care. I was tired of pushing for what I mistakenly assumed were basic principles.
Know your limits. Be open to new ideas. Be humble
but don't compromise your own principles. You do know what your own priniciples are, right? What you would compromise on, what you wouldn't?
Good luck out there.
There are a couple of reasons for the NDA that may not be apparent to a casual reader - Full participation in a forum that is defining a new industry standard necessitates learning about what some of your competitors may or may not be doing. This has nothing to do with Open or OpenSource. Anyone at all familiar with security technology will realize that the issues here are not the software algorithms (these will be cracked) but the physical means of securing the shared keys. The interfaces are OPEN - anyone can code to them. The software can be OPEN SOURCE, but there are large economic incentives to protect your code in this space. Signing a long term agreement with a major MSO (see Moto and SA) virtually guarantees years of huge profits. The security keys must be physically secured. Has nothing whatsoever to do with the SW implementation.
Slashdot Mirror
You are blissfully removed from the reality of most large software projects. What you describe only works under limited circumstances. Very few corporations will tolerate 40 releases in 5 years, let alone 1 year, they assume your product is unstable and requires too much monitoring and too many updates. You most likely are selling a product to other programmers.
How do you know you are building in quality? How do you know your unit tests are really covering real customer situations? What is the motivation for your average programmer to do any of this? Why put in the effort if management doesn't know the difference? BTW - I agree with all your points, if we agree on what market you are in. But - I seriously doubt that any programmer knows more about what the market needs, than any reasonably competent manager - if that isn't an oxymoron. I *have* worked with one or two reasonable managers in 35 years of doing this. Hell, I used to be one. At some point, you *have* to drink at least a tad of the kool-aid, from *someone*, just to stay sane and believe that you are contributing. However, if your goal is to satisfy *yourself*, then all bets are off. In the world of business, that's absolutely the wrong goal.
Well no. Decisions ARE made about the direction of the product. But these are based on whatever is in management's face at the time, not on any actual process of thinking or planning. And then, the manager moves up, and the next manager wants to make an impact, so s/he changes the whole product direction based on the first thing s/he gets screamed at for not doing. And of course, many products HAVE no meaningful lifetime, so why bother with much planning? Just keep writing code, something good will happen.
So - agile sw happens because smart programmers know that management has no clue about requirements, so why waste time on requirements, just write some code?
There are a huge range of software products out there, one paradigm can't cover all needs. Of course, the biggest mistakes come from applying the wrong process to the wrong market need.
Anything that is intended to last more than 2 years will have substantial maintenance costs, but most managers move on after 2 years or less. No incentive to build it right, ever.
Most developers want to work on something new, leading edge, and they move on as soon as things go into maintenance mode.
It is far easier to react to customer complaints than to plan anything. The excuse is always that we have to keep the customer happy.
A sad lifecycle.
You will get crap from all sides. You will be asked to compromise your personal views in the interest of teamwork. You will be ridiculed, screamed at, and a general target for anything that goes wrong. You will be asked to deal with the most difficult engineers, and the most difficult customers. If you are lucky, your own boss will watch out for you and only 50% of this crap will come your way. Push back push back push back. Protect yourself and your integrity or you won't get through it. Having said all that, give yourself 18 months before deciding if you are cut out for management. Hopefully you will get a chance to manage 2 projects or 2 teams in that time. I just stepped down from 4 years managing a data communications team that varied from 3 to 24 people. It started with 24 (bad start), a total disaster, and gradually got better and better. Personal counseling helped a lot, a professional outside the work environment. Last year my 4 best people were taken away, my schedule shortened and I was made responsible for worldwide product support - in the name of giving me a "chance to grow". I quit when it was clear that my bosses would not budge on anything, and didn't really care. I was tired of pushing for what I mistakenly assumed were basic principles. Know your limits. Be open to new ideas. Be humble but don't compromise your own principles. You do know what your own priniciples are, right? What you would compromise on, what you wouldn't? Good luck out there.
There are a couple of reasons for the NDA that may not be apparent to a casual reader -
Full participation in a forum that is defining a new industry standard necessitates learning about what some of your competitors may or may not be doing.
This has nothing to do with Open or OpenSource.
Anyone at all familiar with security technology will realize that the issues here are not the software algorithms (these will be cracked) but the physical means of securing the shared keys.
The interfaces are OPEN - anyone can code to them.
The software can be OPEN SOURCE, but there are large economic incentives to protect your code in this space. Signing a long term agreement with a major MSO (see Moto and SA) virtually guarantees years of huge profits.
The security keys must be physically secured. Has nothing whatsoever to do with the SW implementation.