(Warning! The Post Below is long and contains High levels of English that cannot be simplified in construction nor theme) Roland, I have Posted at this level to hopefully start a dialogue about development models. Others who have been in a software development role for a long time, will understand why I have introduced the topic now. I will refer to the word 'me', on behalf of those who have seen various development models over the years. I hope the discussion will be fruitful. Is there a division of work between the Systems Analyst and the Programer, or are you still using the 1990's Model, to combine the roles into one person? This may be a strange question to some, but it goes to the heart of production of software that is tecknocratically based in design and function. I can answer my own question very quickly from thousands of miles away, as it is clear you are still maintaining the Systems Analyst and Programer being the one person, and have the dual responsibility. This certainly does reduce numbers of staff, but it was clear in the 90's, that is was fundamentally flawed. It would be a bit like combining the matre de of a restaurant with the head chef. The food would be technically very good, but there would be little on the menu and the service to the customers would fail badly. There is an innate difference between usability and functionality; and tecknobility that always wins. It is not possible to separate the code cutter from the designer, although around the world we tried very hard to do this in the 90's. We all saw software that could do many things, but no one could or would use it, as the interface was not designed around the user. Here I am excluding myself as a user, and everyone who reads this must do the same. We are so boged down with the perspective that, we cannot make a change to the software design because of a technical issue. The user just wants software to work and follow simple logic, but the code cutter puts the breaks on an idea or concept in the first place, because of a technical issue. Lets have a look at a simple example. We all know that once we commit any service driven application in Yast, we cannot stop the process by clicking on the Cancel button. Have a quick look at the following bugs and the tecknocratic response to a common sense problem we have all had. I have excluded my own bug report that precipitated the following bugs and dialogue. https://bugzilla.novell.com/show_bug.cgi?id=442173 https://bugzilla.novell.com/show_bug.cgi?id=489077 The issue is simple, the code cutter says WONTFIX, because its technically 'impossible' or 'too hard' yet the consent is fundamentally logical to the extreme. I the code-cutter, WONTFIX, something that a user find simple logic in. How do we explain to a user they cannot use the Cancel Button, because it wont work and stop a Yast Process that hangs or misbehaves. No user is interested in tecknobabel, the button says cancel, and they want to cancel a misbehaving or hung process in Yast. The chef is dictating what the customer can eat at the restaurant. The whole usability of the project is driven by the programmer, not the analyst. The software is created and changed because of technical reasons, not functional user requirement or simple common sense logic. The role of the Analyst/Programer always opts for the technical change or solution. The users logic has nothing to do with the software's design. The user hates the software because it does not make sense to them, and they don't buy it or want to use it. The CEO's, Private Secretary cannot or hates using the software, and his/her work is delayed resulting in the CEO dismissing its possible deployment until such time as it will. Separate the Business Analyst from the Programer and you will create world class software, that people love and want to use and dump the 1990's Model of combining the roles into one indivisible position. Scott Roland Haidl wrote:
Hi,
this is my first public message to openSUSE project, and that means first I'd like to introduce myself: My name is Roland Haidl aka rhaidl, and I started to work in SUSE nearly ten years ago. In that time I managed the SUSE documentation, usability, design etc. After Novell having bought SUSE I took over several other management task.
Now, while Novell/OPS engineering adopted to a new strategy regarding openSUSE, we decided that the people, who Novell dedicated to work in the openSUSE project, come under my responsibility.
For me that is awesome and something new - as it is in general. Why, since we already had Novell people working for openSUSE in the past? Well, the new thing that with this step Novell decided to intensify its openSUSE sponsorship. Now we have a group of people that is exclusively dedicated to the openSUSE project.
It is not longer the "when time is left, please work in the openSUSE project" thing we often had before, we now have the singular situation to have a team of more than 10 experts in Novell to only work on openSUSE community topics. This is the Novell "openSUSE Team", and it is there to be a part of the community and make it easier for people to join in, enjoy and contribute.
We (speaking as part of the Novell management) learned to trust the community, and, as a result of this, want to support the project even more. For proof let's see how the team will work.
Of course the team also has reponsibilities, that is basically the openSUSE distribution and the healthy growth of the project. Both challenges will and can only be done in a strong community with YOU and I hope you appreciate the existance of the new team as much as I do.
The people working in the team are all well known since they already worked a lot in the community. I leave it up to the team to introduce itself. As the lead of the team we nominated Klaas Freitag, who is an experienced manager on the one hand and a community guy on the other. Henne Vogelsang takes over the role as project manager openSUSE, and Stephan Kulow will continue to be the release manager for the next openSUSE distribution.
Best, Roland