Comment Re:Bunch of BUNK! (Score 5, Informative) 577
It has already been through the courts when Green Hills copied the Threadx API from Express Logic, Green Hills won.
It has already been through the courts when Green Hills copied the Threadx API from Express Logic, Green Hills won.
The process I have seen followed by the most senior developer in my last company was more like:
Write code
Don't write tests
Don't put a label on the trunk
Commit hundreds of files to the trunk
Write specification
Write requirements
Run out of budget
Trunk now abandoned for other projects
He did work "at a higher level to all of you" so what did we to know!
Wanting to get your code reviewed is a good first step. Is you code clean enough to explain to a non-coder? Maybe find someone in the company who while not a coder has expressed an interest in it.
For personal projects it is easy to not apply the same practices you would at work and become sloppy, just do it as you would a professional project. Get unit testing in right from the start, learn about refactoring, take a while off from it and look at it again afresh, if you feel a pattern is wrong or not applicable you're probably right so strip it out and use another. Maybe publish your work somewhere, get involved in forums where you can get advice and also give it. Learn to accept criticism - this is a tough one for most people - me included.
These two requirements, as stated, are common in industry, and are pretty much exactly what Agile is directed at: You release quality product with a limited feature set first tat fills an unfilled need, and then expand the feature set in subsequent releases. You are, therefore, able to both release only quality product and release it quickly, making subsequent improvements that expand features after the initial release, without sacrificing quality.
Good point but in this case, although eventually we (unsuccessfully) went for an agile approach, releasing in this way didn't suit our customers. Each release would have to be re-qualified by them which costs hundreds of thousands of dollars, deployment could be anywhere in the world and if it didn't work for whatever reason they would switch the system off and lose revenue.
I can't agree more. The number of times I have raised issues before deployment only to be told that it is "not a requirement" is beyond me. It is very hard to fix these things afterwards and I suspect that the reason these issues are ignored is because the requirements/software architect (same person in my case) has designed something so inflexible that they cannot change anything. Using something like DOORS is all well and good but garbage in still results in garbage out.
Our QA department doesn't have a single person with a background in software and when I raised this concern to the engineering manager he didn't see my point.
We had a general manager who said that only quality products should be released to customers and as engineers we wholeheartedly agreed with him. The problem was that the vice-president of engineering had the view that it is best to be first to market and you can make it better after it ships. The general manager also said that he would not entertain a project that returned less than 40c on the dollar, yet the company only made 6% net profit in exceptionally good years and usually more like 2 to 3%.
I remember doing layouts by sticking tape on acetate sheets, cutting the tape tracks with a razor blade - health and safety would not allow that now I imagine.
How does it go again?
Those that can do
Those that can't do teach
Those that can't teach (project) manage
That is why the company will ultimately fail or give poor value for its shareholders. Read about the Peter Principle if you want to be driven to more despair.
It seems then that you are having a working lunch everyday if all you talk about is work. That may be ok for some people but others just want to get away for 30 minutes or an hour.
In my case I am a task orientated person. I have had to learn that some people are at work for more of the social aspect than I am and that although they are not as productive as I am they still provide overall the same value to the company that I do. I have to accept that my boss is my boss because he has better judgement than me in some matters and that if he does not then his bosses will find out and address the situation or the company will fold. Basically shit will happen so don't fight it, a good company will flourish and a poor one will die.
Your attitude seems a bit poor too. Some people are task orientated while others are people orientated. It is very difficult for task orientated people to see why they are not more valued than the others who seem to goof off all day and yet get paid at least the same or maybe even more. I have been through this myself and it took a change of job and a couple of good books to realize what was going on. You should be more aware of the different types of people.
I think you will find it is Asberger's not Asbergers.
If you want to be in management and want to be liked then you are not suitable for the job.
Express Logic have already been through this when Green Hills released their RTOS using the ThreadX API from Express Logic. In this case the arbitrators ruled in favour of Green Hills even though the header files were copied.
"It's the best thing since professional golfers on 'ludes." -- Rick Obidiah