As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Programmers often serves as a designer of user interfaces. You could argue whether it is good or not. However, especially in small companies, it is a reality that does not change.
What do you think personally as a programmer, is it our work to design UI? Personally I think that not, especially when you are going to work on Web Applications, where they made you to design UI also.
****Correct me if I am wrong.****
In an ideal world there should be a UI designer, just as there should be a DB designer, etc.
However, this would mean that even the shortest projects run by the smallest companies would need a team of at least 3 (or more) people. Because of the cost that this would incur it's never going to happen.
On small projects you are going to have to double up job functions in fewer people. It's a fact of life.
From a pragmatic point of view I think that all programmers should have an understanding of the basics of UI design, if only to be able to spot a bad one and do something about it. I also think that programmers should have an understanding of DB design as well.
You should look on this as an extra skill set you have which will give you more options when looking for new career opportunities in the future.
A GUI designer should design user interfaces. This is a different skill set. Of course, there's no reason why you shouldn't have someone in your team capable of performing both roles well, but it is important to recognise that the roles, and skills required, are different.
Should a programmer design User
Interfaces?
Only, If you're working in a small company or freelancer - one man army with limited team-size, where you often have to wear different hats of a programmer, tester, QC and the UI designer. This would not be the case for larger companies, where teams are large and responsibilities are divided horizontally or vertically.
Personally, I prefer working on projects where I have a view of the full application stack, so, for a web app, I'd hope to work on the UI, presentation, business and persistence layers.
I like to fully develop a 'feature', rather than a layer - it makes the work feel more real; but then I'd say that I'm probably not typical in that regard.
Also, I've found on projects where the work is divided by layers that there's (necessarily) a much bigger overhead in agreeing on the interfaces between different developers work. Arguably, of course, that's a good thing, because extra up-front design can only improve things, but I found that huge amounts of time were wasted with people waiting for others, and fixing thing that broke from a seemingly innocuous change.
Of course, there is a very different skill set, so you either need good all-rounders (who are probably less good at the minute detail of individual areas), or strong leaders for each technology. But I think the payback is fewer integration issues where everyone's code works perfectly, just not all together!
Some Web Application requires some good designs, you are right at that point. Thats because there are designers. For example, I am really bad at design. A programmer should have own Design Patterns on coding :). Of course, if you have a good idea on how to design, it should be good for you. You can both write & design your UI however you want. Be pro on coding, let designers design your UI :)
Good Luck
You have answered your own question i think, i have worked in companies where i would not be doing this and also companies where i would.
If you work on line of business apps the UI may not be a top priority and therefore a programmer is usually capable of this task.
I think a programmer can design UI well given the correct training. My university had UI classes, and there are short seminars / training classes out there today that hash over the basics of good UI Design. The important thing is to know your customer well, and the real use of your website - keep in mind that this may differ from your intended use. I.E. you may have intended one type of user to use your site in a very basic way, but it turns out it has become a favorite of expert users, so the UI needs to support that.
Often times your buying customer, if you are offering "solutions" rather than "products", will dictate large portions of the interface, right or wrong, so the affect of your design expertise is limited anyway. The important skill to have here is communicating the whys of your interface, and the why not's of theirs.
Programmers, generally, design horrible UIs.
I think the ideal here is a UI designer with some programming knowledge. While they will focus on the user's experience, they'll also know how certain UI decisions may have a big impact on the underlying implementation.
It depends. In a small company, of necessity programmers will also be designing UIs, so yes, it is your job. In a larger company, there may be others on the team whose job is to design the UI, so then no, it isn't your job.
The question here isn't "should programmers be responsible for designing UIs". In some jobs they will be, in others they won't. Some programmers enjoy designing UIs and are good at it, others don't. If you personally do not like designing UIs, then you should take jobs where you are responsible solely for writing code and not designing UIs. If you are currently in a job where you are being asked to design UIs and you don't want to do that, time to talk to your boss to see if there is someone else who could do that function. Say you don't feel UI design is a strength of yours and you want the company's product to be as good as possible, therefore is there someone else who could help design the UI? If there isn't, start looking for another job that better fits your skills and inclinations.
The team I work in is very small so we are all involved with the full software lifecycle, although we do have a dedicated QA team too.
Ideally not, but it's mostly better than the client designing the UI.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I work in a company where, since I arrived, I had full freedom to use whatever Microsoft technology, pattern and tool in order to develop my applications.
I started to develop all the applications with ASP.NET MVC3 and I currently have 5 applications deployed and working.
The other day I had a meeting with my manager to review all the applications and he realized that my code was completely different than what he expected. He basically realized that I do not use Web Forms and that I use MVC instead. He thought he was just some component/tool and not a totally different approach to programming. He was curious and he briefly studied what ASP.NET MVC was.
After two days he said that I need to convert all the applications to Web Forms and use just Web Forms from now on. He says that MVC resembles the old asp(that for certain aspects is true) and that it takes longer time to develop the application and makes people confused when there is the need to change/maintain the application.
I think it is not true because, after a steep beginning, I got used to the magic of MVC and it eases development, componentization and maintenance of applications.
I said him that Web Forms is too coupled UI/Logic/DAL, after a while the code becomes unreadable and it jeopardizes unit testing. I also shown the possibility to replace the old GridView(one of his main concerns) with the jQuery or MVCContrib grids.
There was no way to convince him. Both for work and personal development I do not want to take a step back to Web Forms, therefore I kindly ask you to tell me the most important points that make MVC "superior" to Web Forms.
Thanks
Unfortunately, it's not uncommon for a manager to give a business-speak-laden version of "I don't understand this, so I want you to do it my way instead." This often stifles progress. (I've actually left jobs in the past for this very reason, managers who refused to allow any development that they personally didn't design.)
However, you also need to keep an open mind on the subject. He may very well have good reasons for this. Supporting the code is a big concern, and while I agree that it's easier to write clean and de-coupled code in MVC, at the same time he might be seeing a market where it's much easier/cheaper to hire farmed out developers at low cost to support a WebForms application. He may have a stack of resumes in his drawer that paint a very different picture between WebForms and MVC.
The best thing you can do, really, is approach both paradigms with a completely open mind. Understand that the rumors of WebForms' demise are greatly exaggerated. So if you really want to convince him of anything, then you're going to have to present a proper and unbiased comparison.
Start with a simple pros and cons list to compare the two paradigms. Make sure you don't skip on anything. If he has pros for WebForms and cons for MVC that you tried to ignore, that'll hurt your case. Evolve that list into some examples, demonstrations, proofs of concepts, etc. Make your argument tactile, give it numbers and tangible values that mean something real to management beyond just "this is a better development strategy." Quantify it.
If you approach this with an argument that says little more than "well, my way is better because it just is" then you're not going to get far. Even if you have a point to make, you have to successfully make that point to him. You have to put it in his language.
This is really less about which development strategy is better and more about communication and clarifying your ideas. After all, if you can't defend your position then from his perspective it's not a good position.
And if you fully clarify and quantify all of this, and it's critical that you keep an open mind about WebForms, then what you've done is given him the information he needs to make an informed decision. That decision may not change. He may still insist on WebForms. But it's his decision. What you're doing here is presenting him with all the pros and cons, all the costs and benefits (both immediate and long-term in terms of re-writing what you already have and ongoing support and all of that). If his decision turns out to be wrong, at least it will have been his informed decision. You won't have kept anything from him.
In the end, he may still insist that you do things the way he understands them. Some managers are like that. But take this as an opportunity for your career to master the art of presenting an argument. It won't be the last time you find yourself doing this.
I would search data or survey result showing superiority of MVC projects rather than telling him how good MVC is. MVC is just more productive way of creating & maintaining quality software. One thing I would like to add is that since UI is completely decoupled with biz logic, it is a lot better to automate code production with code generation tools such as T4 and MVCScaffolding.
WebForms was created to make it easy for WinForms developers to move to web. ASP.Net MVC's main benefits are that it separates out the Model (data), View (HTML,CSS,jQuery) and Controller (logic and routing). This allows different people to work on different parts if needed (separation of concerns). It also is much closer to a true web model, designing using HTML directly rather than this being abstracted away by ASP.Net User Controls. Obviously, in MVC, you have the HTML helpers and can make your own custom helper extensions as well as using DisplayFor and EditorFor templates.
The bosses argument is that many developers will know ASP.Net but not MVC, so it will be easier for others to work on it. However, MVC has been out a while now and many keen developers will have already picked this up or can do very quickly. It's a very clean and powerful way to develop web applications very quickly and easily maintainable in my opinion. ASP.Net of course has its advantages too but you asked "what makes MVC superior" so I've just argued a few benefits of MVC over ASP.Net. This is by no means an exhaustive comparison and hopefully others will add their opinions too.
I have been developing websites for quite some time and I am not so good in designing websites? My Boss is refering me to take some lessons on it.
But I really want to stick to development rather than designing?
You don't need to be a designer. But I would highly recommend you understand the process and some of the techniques used. Having that knowledge will assist in both working with designers and providing better back ends.
I'd do the course, but make it clear to my boss that it's not what I want to do as a main job.
Answer yourself these questions:
What is your objective, the dream? developer or designer?
What are you best with?
Will I be able to justify with my design requirements?
It this common that a developer should be a designer too?
Will you be able to to concentrate on both, the ever changing trends and techs.
Having said that, I have seen such people having both skills but still they don't weigh equal in both parts.
Developer as well as designer:
Chris Coyier of css-tricks.com
Pekka
It depends on what you want to be in the future. Actually, designing and programming are two different skills. Obviously, for websites two things are both required. As a developer, if you have some basic knowledge about design, it would help you and also the designer to make the website much easier to maintain. But personally, I do not thinking you have to dive into design.
a good developer knows a lot about design, but dont have to be good at designing something.
i've seen to many developers building up a given design and making so much mistakes, because they don't see the little intricacies that are enormously important for a well designed website.
One particular design aspect I find many developers (good ones) are not necessarily extremely strong at is understanding of colors harmony. Even though it seems like easy thing to do, find the right combination of colors on a page, it is not always that easy. That course may be helpful in that regard.
I started of as a developer and then progressed into being a Developer/Designer.
You start to understand design aspects, UX aspects and the likes.
So i believe a good developer should also have a good understanding of design aspects as well
The bottom line is your boss thinks you'd benefit from a bit of immersion in design, and you probably will.
It doesn't sound like he wants you to become a designer, just get a feel for it. He's not asking for a career change.
There's always benefits in learning something new. And if your boss is backing you taking some time to do it got for it.
As a developer you should know something about usability and software ergonomics. You should know the basic structure of a website. And you should be able to implement a given design.
I think it is not the job of a developer to create a design.
Try to answer: "Why does your boss want you to improve skills in design? "
Your team is too expensive and boss is going to fire designer. He is wondering is it possible.
Your designer complains to boss that developers constantly ask him to refactor insignificant details interrupting from common tasks. So your boss wants to delegate small design decision to developers.
If it's so, I think nothing is a bad to improve design skills if your boss doesn't want you to convert to designer.
I also agree with all those people, who state: Developer and designer are two different roles.
Well, if developing is the field you are comfortable with, stick with it.
But learning is never bad. Try to gain knowledge first, after taking the classes, you can answer this question yourself
Wow, I'm actually in the exact opposite of your situation. I'm a designer just crossing the line of web development. But in my case, it was my own decision and it wasn't imposed by anyone.
It's always a plus if you have web development skills on top of design skills. I guess it holds true if you're a web developer and have design skills as well.
It never hurts to learn the basic, like others have mentioned, but keep in mind to stick on what you're good at and master it. Its better to be a master of something rather than being a jack of all trades. With so much competition out there, you really have to excel at your craft.
Learn both, but master one, I'd say. I personally see myself as a developer foremost, but I do know a thing or two about design - and, more specifically, implementing it (think CSS and the like).
However, I gratuitously admit that I am not good at making a design that looks good. A functional one, maybe, but not good. You could say something like that to your boss - that yes, you are capable of learning to design, however that you will never be as good as a real designer. Likewise, a designer learning to program will never be as good as a dedicated developer.
I work in a small and young team of developers and we have problems that we are not sure how to solve.
On previous projects every developer have been working on tasks that were based on use cases. So, upon setting the system architecture, each team member worked on user interface and business logic of tasks assigned to him.
This kind of organization gave us the problems with UI. Each developer had his own logic about how UI should look like, where buttons should be, etc etc... and even if we've had one css designer a lot of refactoring had to be done in order to make web site to look compactly.
How do you deal with this issue?
Do you split tasks based on layer, not on whole use case?
Do you use some technical solution to achieve this or is it just written standard that every developer need to follow?
Thanks
Everyone has their own style and it would be difficult and a waste of time to define a standard that would get everyone to draw the UI in a consistent manner. Instead, elect your best UI designer to do what he does best and design the UI for the whole system. Funneling all UI changes through the designer would be difficult so just let your developers "mess it up" as they implement new use cases and just have your designer clean it up before the release. It shouldn't be hard for him/her to rearrange the existing forms and bring some consistency back to the UI.
I've found this 12 Standard Screen Patterns article very useful.
A solution might be to create sketches of all screens of your application, have them reviewed by an ergonomy-expert to correct the biggest mistakes, and, only then, give them to your developpers.
This way, they would know how the screens they are developping should look like -- there will still be a couple of differences in the end, but those should not be "big differences", and should be eaiser to fix.
And this would mean not each developper has to imagine what the perfect screen would look like : each one of those would be coherent with the others.
Adopt the tried and tested MVC system, let the view be decoupled from the business logic. Then ask a UI designer to produce sketches and work to that. UI's are something best done top-down from my experience. The user gets an overall view before being presented with all the details, defining and capturing this hierarchy makes good UI's. Coding of business logic is done as you mentioned on a use-case basis, mostly bottom-up and this is where the code falls out of sync with the UI.
Designate one person (preferably someone with graphic design experience, even if they're not really a programmer) and give them the authority to make cosmetic changes to all forms, pages and controls at any time, and have them be responsible for the overall look and feel of the application.
As far as metrics go, keep track of how much time this one person has to spend "fixing" each programmer's work, and make sure the programmers are aware of these numbers. The idea is to encourage them to make their stuff look like it should from the beginning, but also not to do weird things based on what they think stuff should look like. I've had to spend more time undoing my coworkers' bizarre design choices than anything else.
Don't be afraid to have outside sources review the design work of each programmer. It's very common for programmers to 1) produce horrible-looking UIs, and 2) believe the UIs look fantastic. You should do what the Army does with boot camp: break them down completely right from the start, so that you can build them back up again the right way.
Part of the problem with creating your own written standard is that while well meaning, there could be mistakes or better ways to do things than what's been standardized. For example, where I work, the standardized cancel button does nothing when you click on it (it's been wired to Reset).
Instead, I recommend choosing existing standards, such as The Macintosh Human Interface Guidelines or Windows User Experience Interaction Guidelines. Even if the standard is wrong, it's rarely profitable to deviate from widely established conventions.
Then pick up some good books for the developers, such as "Designing Interfaces: Patterns for Effective Interaction Design". Good user interface design is partially a matter of good taste, and while not every developer will be interested in the subject, it's in your best interest to help them improve.
Next, empower your QA team to file bugs when the interface for one product is inconsistent with another. The developer can then either standardize or justify the deviation if he has a reason. We do this; it works pretty well.
Lastly, go over your existing products and get a consensus on how their interfaces should be unified. Bring in (and keep) a usability expert if you can. I've seen good ones do amazing work.
There really is no clear solution for how to deal with UI problems. There are however several approaches one can take to combat the problem of having things become too complicated:
Use cases are usually cross disciplinary in nature, thus the responsibility to get a use case done should be split between the people who can implement it properly. Programmer and designer type of people need to cooperate.
Everyone in the team needs to keep in mind seperation of concerns, i.e. things that can be seperated must be kept that way preferably as early as possible. There are so many ways to do this: e.g. apply MVC pattern in your project (which is a very wide way to put it). Presentation and logic should be seperate so that changes in one layer should not affect the other.
Someone needs to be responsible for the overall UI design so it is consistent throughout the application. Preferably someone who is both a graphic designer and has some insight in usability. UI design is something that needs to be planned along with the use cases and revised constantly as development goes on. Consistent UI is very important and developers need to be on board on it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Let's say you work for a huge company which suddenly decides to do custom in-house software development. Additionally, they want to be able to offer successful developments to their customers as well (if any).
Now you are in charge of it.
What would you see as most important to build a successful software development infrastructure?
flexible to future growth
flexible on used technologies (projects with c, java, .net, web, mobile, ...)
What kind of tools (source control, forge, ...), hardware (virtual, seperate dev & production, ..), processes (guidelines, code reviews, ...), etc.
UPDATE: Please don't answer that you need the right people and the right tools. This is exactly what i am looking for.. What are the right tools and what people of what type would you hire first to join your team? Think of it as you will be the lead of that development.
Set yourself up to pass the Joel Test with at least a score of 10.
I think having the right people is going to be the most important. Nothing else will matter if your programmers stink.
Someone in charge who knows what they're doing.
Obviously, there are lots of factors, but here are the ones I'd say are crucial:
Hire smart people (and pay them what they're worth)
Select good tools appropriate for the kind of development (don't go for cheap tools)
Establish version control system and policies
Establish testing mechanisms and policies
Don't be afraid to outsource the stuff you don't know how to do
Get the best people for the job. If they aren't willing to pay for the best available, or give you a hard time over your personnel budget, you're off to a bad start.
Get the right tools for the job... software, hardware, support contracts from your vendors, etc.
Establish procedure early on for your development life cycle, and make sure that you have the people in place to make use of it. This is everything from how you evaluate Opportunity Assessments to Development, Testing, and post-production support. Make sure you have the people and the tools for each part of the life cycle.
Dont try to be flexible in technologies. First start by focusing on one technology (Java, .NET, whatever...) and then move to other if you need to. You will be able to solve problems using any technologies, but it is very hard to find people good in many technologies.
At the infrastructure level, Source Control is a must. Continuous integration is a plus. Take time to put in place a standard project layout that you will be able to evolve. It make it easier for developers to switch projects. Take time to put in place a good build process (Ant, Maven, in the Java world). Integrate your build process with your IDE so that developers dont have to wait 5 minutes to deploy their project every time they want to test a code change.
I agree with Guillaume: If you want to build a department from scratch, you need to focus. You need to build your team, have everybody grow into their new responsibilities, get to know each other etc. Trying to go into too many directions at once is the direction towards failure.
So, identify the technology you want to develop in. Since the primary goal in your example is in-house development, the in-house requirements will determine your decision. Build your team with that primary goal in mind.
For in-house development, you need at least two people who already know the company and its processes. (Two because one will definitely be ill or on holidays when the first major crisis hits you). On the other hand you need some outsiders, who are not entrenched by the "we have always done it like this" mindset, who can think out of the box. Those should also be at least two people, for the reason stated above. Your job as the team leader is to balance those two groups and integrate them into a team.
For future growth, always think in terms of organic growth.
Do not increase the team size by 200 %, hire one new guy here and another guy (or gal) there. Slowly build your team.
When you take on a new project, always think of expanding your teams expertise. Try something new with every project. That can be a new source repository, an automated daily build process, a new system to write specifications or documentation, or even a different technology (for example Java when you usually develop in .Net, Delphi or C++). Just make certain you never try to make a big leap in an important project. (I once worked for a company who decided to switch from VB 6.0 to .Net for the biggest project they had ever attempted before. They survived. Barely.)
That way your department will slowly but constantly expand its capabilities. Then when the opportunity presents itself to do development for an external customer, you will already have accumulated most of the knowledge you need in order to pull it off.
Oh yes, and smacl is right, too: You need solid QA/QM if you want your department to survive long term.
Start laying out (and follwing) your QA rules from day one. Keep them as short and flexible as possible. Add what you discover to be missing, and throw out what proves to be unnecessary or impractical.
Not sure this is what you wanted to know, but I felt the need to say it ;-)
Develop a strong QA strategy, including acceptance criteria and change control. Preferably keeping it lightweight to suit internal clients. In addition understand how to carry out requirements analysis, expectation management, and resource management.
Put another way, don't just wing it to create crappy solutions that waste more time than they save and are impossible to maintain. Take time to think about what you want and need, how you can achieve it, and what it is going to cost.
I will offer an answer more focused specifically on coding and the developers / architects role in addition to the previous answers on teams, version control, qa etc. which are of course all important.
Many of your decision is very dependant on your specific business and software structure (a single product code base, SOA, many projects etc.) But in general you should always spend significant time up front developing Core Software Infrastrcuture that will pay huge dividends during the SDLC.
Software infrastruture
Coding Naming Conventions Exception
Handling strategies Logging
Strategies Settings and Configuration
Base classes and Helper Classes
General Architecture and Layers
(Presentation, Facade, Domain
Entities, Data Stores etc.)
Design Tools such as UML 2.0
Requirements
Management / End user interaction
There are tons more, but these are certainly some basics to think about. All of the successful projects I have been involved with incorporated decent software infrastructure. I will also note that many of the project that fail have a common theme... lack of a common infrastructure in place. In most cases these failed projects are lead by a non-technical person that think they can simply throw a bunch of ideas at a few programmers and expect them to deliver in a few weeks.
Bottom line, you need to invest some up front planning and prototyping to ensure success in the long term!
Good luck.
Raiford
www.blacksaber.com
The first persons you should hire should be experienced senior level professionals. Then build up from them / with their input. Add the junior people later.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
We are looking at hiring a software development project manager. His job is going to be concerned with running multiple dedicated project teams focused on delivery of software for external customers. He will also need to provide support to our business development unit and oversee post-implementations support of the aforementioned software. What level of hands on development experience should we expect from the applicants? Successful candidate is not expected to do any coding.
Not important. We should be focused on proven project management experience in software area.
None.
Some experience, exact technology does not matter.
Heavy experience, exact technology does not matter.
Some experience involving same acronyms as we use daily over here.
Heavy experience involving same acronyms as we use daily over here.
Some experience, mostly with technologies we do not use.
Heavy experience, mostly with technologies we do not use.
This question is regarding the best level and quality of required technical experience and is not concerned with any other skills and qualifications of a software project manager. Many thanks.
As with any position, you need to assess first and foremost what skills and experience you need on the team for you to be successful. Then hire to fill the gap for the skills that you do not already have on your team.
If you already have a team with strong technical and technical leadership skills then you don't need to hire someone who is likely to compete with the people you already have. If you are missing this, you probably want to hire a technical manager with some project planning and tracking skills.
Great project managers are those that are multidisciplinary - they are most successful where they can bridge the divide between the various stakeholders and team. The primary role of the project manager is to manage risk and facilitate communication and collaboration. As a minimum, you should look for someone that has proven experience in either your industry or with the technology space that you are playing in, otherwise they will be unable to gain the respect of the rest of the team and perform their primary role.
Which brings me to something else you should consider carefully - what is your culture? For example in a previous job, we had development leads that were very strong technically and wilful. Project managers were always relegated to second chair, and pretty much ended up as glorified MS Project admin. assistants. Anyone good did not stay long. What do you need to do to allow the type of skills you want to acquire for the team to flourish?
Most of our project managers have zero technical experience, so I'm guessing the skill sets are different enough that it's not necessary. However, they have to be bright enough to grasp/learn the concepts involved in development -- just not the implementation.
That's not to say that a technical background would be a bad thing -- it could be a "nice to have". Then again, it could possibly get in the way and they could try to control the implementation.
In my experience the very best technical managers I've had had very strong technical backgrounds (and usually were a little reluctant to trade herding code for herding coders). The worst were the the ones that were merely average programmers at best and had more of a management background.
The tentative conclusion I've drawn from this is that while not all programmers are management material, all good technical managers started out as good programmers.
Note that this answer is coming more from the perspective of hiring an engineering lead. For a project manager - someone whose job is to interface between the technical people and the customer - technical acuity is probably less of a requirement.
Some technical skill would be nice, but far more important is that they understand the functional area your company exists in. So if you sell an OS, then you probably want stronger technical skills than if you're writing banking software, for example.
Go with point 1. "Not important. We should be focused on proven project management experience in software area."
Edit: (after re-reading your intro-para) Seems what you want is a product-manager, and in support you need team-leaders on the diverse teams to handle and report on the technical issues. (Also since customer-contact is involved: a little marketing experience won't hurt!)
As an aside:
You are focusing on the wrong skill-set. You want proven administrative skill; proven organizational skill; and above all: proven people skills - (s)he must be able to communicate without antagonizing or patronizing the audience. The technical staff and programming staff will have all the necessary experience in development. (S)He must be able to manage and control these staff members effectitively.
The manager has to be able to communicate with developers. This either requires a decent technical background, although not necessarily with the same technology, or enough humility to know when the developers know more about something than the manager. I've seen both work well.
I think what I'm saying is that having respect for the developers is important, and there's two paths to it: understanding what they do, or understanding that you don't understand what they do.
Answer is "4".
Heavy experience with some technology is critical. I know the mindset is "project manager does not have to understand technology, he just manages people".
Well no, PM does not manage people: he manages project that is supposed to produce some deliverable that is acceptable at least across some desired aspects (capability, performance, reliability, security, maintainability, etc). If he can't understand technology, he's lost. Of course, he does not have to be an expert in peculiar technologies used in a project: but he has to be able to filter BS away, to question programmer's estimates (we know how those go), to feel at least technical risk here or there, to be able to formulate business ramifications of particular technologies.
In some ways I think that PM's challenges re technology are even bigger than those of programmer: he has to be genuinely interested in technology, yet he can't / should not have any technology bigotry, to be actually fair towards them (what they are actually good for and what they are actually not good for).
Read "In search of stupidity" for evidence how non-technical managers drove many tech companies into the ground.
This is excellent summary by Spolsky: http://www.joelonsoftware.com/articles/Stupidity.html
Now, the small print #1: not every programmer will make a good PM, of course. In short, control freaks, toxic personalities, egomaniacs, people who are good at coding but not at negotiating, people who are good at coding but yield to pressure too easily -- will FUBR their projects.
Small print #2: It might be possible that people with very good analytical skills might make up for lack of experience with technology. I've worked with people who were excellent business process and procedure designers, who instinctively understood how UI should be organized and what the software should be doing in this particular place and why and who could detect BS quickly even when served by domain experts but who could not program if their life depended on it.
Most has been answered already, but I'll add this:
Keep the same mindset that you would have when hiring an office manager. While the technology knowledge is important, you'll find that ambition, a will to learn, coupled with a team leader attitude will get you a better manager than looking at mostly technology knowledge. Most projects have some company/industry-specific skills that are involved and a quick learner / great leader will bridge that gap quickly.