Our company has recently decided that a good section of our IT department is actually doing product development and not internal IT development and now has created a new department.
What are the types of changes that developers should be looking to make during this type of transition?
Is there really any difference between internal development and product development?
I don't know how quickly the differences will assert themselves in an existing group which is transitioning from one role to the other, but having worked as both an internal developer and a product developer, two huge differences leap to mind: requirements and and testing.
As a developer of internal tools, I was pretty much given free reign regarding interface, organization, and even scope. Specs were in the form of an email saying "can you write something that does X?" Similarly, testing was almost non-existent. After whatever testing I was able to do, the tools would be deployed directly to their target audience and bug reports, when they came at all, were directly from those end-users, again usually via email or even hall-tackle.
Now that I'm doing product development, the difference is dramatic. Specs are 30-100 page Word documents and we have a dedicated testing department which makes darn sure that what we produce matches those specs. I'm much better supported by the project managers and have clear channels for any feedback I have on requirements or design. It could be argued that product development offers less freedom to the individual developer, but in exchange for being part of a (hopefully) better-organized and better-supported team.
[I work with Jeff.]
As others have mentioned, a key difference stems from the nature of the user:
When developing internal applications, you're typically dealing users from a single department or group who use a limited number of apps, and they're mostly a captive userbase.
When developing external products, you're dealing with users who see the whole enchilada, and they're paying customers who can take their business elsewhere.
That difference matters because a coherent user experience across multiple applications becomes much more important for paying customers who see the entire set of apps.
In the IT case, neither the business nor the users themselves are typically concerned about the fact that their app doesn't look and work like some other app that some other department uses. And if for whatever reason they did care, their ability to do anything about it is more limited. While it's possible to make a business case for consistency across apps (branding to internal employees, usability for employees who use multiple apps, reduced development costs resulting from the reuse of common libraries, patterns, services, etc.), this kind of concern typically takes a backseat to the development of new business functionality.
In the product case, the users do care about coherence across the entire set of apps, and they can do something about it if the experience is weak.
So one major difference is the relative importance of a coherent, quality user experience. But that goal itself has significant organizational ramifications that we're already starting to see.
We'll see an increased emphasis on "horizontal" activities that seek to establish standards and improve communications across teams, since such activities directly support the goal of producing coherent products. Cross-cutting teams (like user experience) will become more influential than they formerly were, we may see new cross-cutting teams (e.g. teams that look at architecture across many systems rather than just a single system), we'll probably see more presentations about what different apps do, more cross-training, etc.
App development teams will have less autonomy than they formerly had in charting their own course. The user experience team (working with end users, business stakeholders and engineering teams) will specify standards around visual design, interaction design, etc. and the app teams will be expected to adopt those. We'll see test practices become more standardized. Builds and deployments across apps will be more uniform and coordinated. Monitoring, alerting, response time SLAs and other operational metrics will be more uniform across apps. The app teams won't be able to define these for themselves anymore (though they can certainly contribute to the larger discussion).
Management will increasingly allocate resources in a way that seeks to optimize globally across the entire product instead of optimizing locally for individual apps. So where in the past the composition of individual app teams has been relatively fixed (developers, SQA, etc.), going forward we should expect to see more fluidity.
A huge difference is in your customer. IT developers have the rest of the company (and sometimes partner / subsidiary companies) as their primary customers. The Product Development developers have customers (i.e. the people who buy the product that is the companies reason for existing) as the primary customer.
Yes, very much so. There's a huge difference between performing an activity that drives revenue and invoices and one that's perceived as overhead.
My experiance is that people working on product development side of the house have bigger budgets, better training, better travel and more skilled employees. Having worked in a product development company it always felt like the lower skilled employees were thrown over to IT department.
In-house development is very process-orientated. They just want to deliver xyz functionality and have it work based on a company-wide strategy. It's not the iterative make-the-product better cycle you get when your primary product is your code. As a result, in-house stuff is often just 'good enough' whereas software companies probably tend to try to improve their product long after it 'just works'.
Note, in-house dev teams can get away with being 'good enough' but software development companies can get away with it for a while but will ultimately lose out to the ones who strive to improve.
I think moving between both environments could be a shock to the system in either direction but that's not to say they both can't be run in the same way - just that in my experience they probably won't. For example, UI is usually given a lower priority when it is in-house software as the customers are generally getting paid to use it rather than paying to use it.
I have been equals amounts of time in both types of organizations. The particular organization where I worked where the software development was part of an IT department treated the development of software as a cost center, where as software development as part of an product was seen as a profit center.
The two are very different. The skill level of developers in my case was vastly different-- those working on a public product were overall better skilled and cared more about the quality of their work. As a developer of a real public product you are actually making the company money.
In my internal software job I typically had a set of known fixed requirements mostly worked out. I designed a solution, but was always given a deadline that was unreasonable if quality was a concern (including code quality), rushed the coding, and delivered the result. Any bugs found that passed any short QA process typically only got fixed if they made formal requests for fixes.
Product development in my experience is almost the reverse. All the requirements are not fixed (only what I was working on for that week was fixed), design is usually dictated by someone who has worked on the product the longest. I get decide how long something takes (but got to really explain why and justify the time), and coding is usually not rushed. Experimenting with ideas generally is more difficult in product development because a product that is meant for public use should use tried and tested approaches.
Therefore, I would say that if creativity is really important then product development may not be for you because a particular idea that you personally have is unlikely to ever make it into the product unless you can make a business case for it and somehow make it more important than what the business has already been planning.
Choosing a particular library is also more difficult depending on how the software is deployed. For example software used by the government typically has to pass Common Criteria certification, which can eliminate certain library choices.
Related
We are going to develop a medium-large customized web app for a private company using MVC 4 and EF 5.
Early analysis and previous experiences on that business field show that it will have more than 150 tables/entities and because our customer isn't a software engineer and we know that our data model will change many times through the progress of the project.
Now, my Q is which approach is better for us according of the following:
1) Causes less effort on updating data model and data store because of many changes that will occur.
2) Takes less time to create the data store and helps progress the project faster.
Note: This app will work with big sets of data (10k, 100k objects for some entities). However, it will have few (and maybe sometimes no) concurrent requests and online users.
Thanks in advance
I think the term
because our customer isn't a software engineer and we know that our
data model will change many times
Is a reality but is not the whole reason of data model change in many times!
BTW some suggestions may be helpful
Consider business analysis a key point and do continues business analysis
More and more investing on analysis will cause less cost on development and change management
Have a specific talented analyst as a representative positioned in the customer office.
Have a specific representative of customer accountable for analysis and development team.
Document the customers business process, talk about them with the customer. Document the negotiation results.
Design and change management
Never design the database alone. Brainstorming team member, invite customer representative, invite business analyst, have a DBA in design team, have a Change-Manager role.
Technology
Have a look on technology trend (may using a document-based database will be helpful)
Have a flexible framework and architecture in service of business software production and not in reverse!
Changes will come ... be ready
Changes will come, all above efforts are targeted to optimized the solution to cost less when change happen, they will not prevent the changes.
You need to have an acceptable mechanism to bill them to the customer
ITIL's Service-level management, SLA and OLA will be a guide line.
So the question answers:
1) All above will help on the problem. Continues interactive analysis first, next design and develop in iterations, using template approach.Changs will come and they will cost.
2) Depends on technology and frameworks, there will be tools (I don't know EF) just don't insist on a specific platform or library.
Hope this helps.
I can recommend you to use CodeFirst structure. Because your classes will be clear and mainly you work with classes much in business logic.
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 5 years ago.
Improve this question
We are planning on introducing Agile into our development process (a shift from the waterfall we've been using so far). We are leaning towards a hybrid model in whcih the requirements gathering session is comprised of a business analyst, subject matter experts, technical person and a user interface person. The plan is to create user stories that the development team can use in their agile process with 1 month sprints.
Has anyone had experience with a hybrid model? How has it worked for you so far?
The plan is to create user stories that the development team can use in their agile process with 1 month sprints.
Some remarks:
1 month Sprints is IMHO too long, especially for an adoption and I prefer to use 2 to 3 weeks Sprints. During an adoption, shorter feedback loops give you the opportunity to inspect and adapt more frequently and since you are experimenting, this is in general appreciated.
I don't really understand what is so hybrid in your requirements gathering session as long as the goal is not to create the "final" list of fine grained Product Backlog Items in one shot (a backlog has typically a pyramidal structure with fine grained items at the top - for the upcoming iterations - and coarse grained items at the bottom). Having story-writing workshops ahead each iterations is a common practice.
PS: While I respect Péter's opinion, I have a slightly different one. I consider Scrum (we're talking about Scrum, right?) as a minimal and finely balanced framework and recommend to stick as close as possible to doing Scrum by the book. Sure, the goal is not to be Scrum but to deliver working product increments. But unless you have someone experienced with Scrum in the team, you (as organization) are not really qualified1 to alter the framework (and to understand the impacts) and might not get all benefits. Scrum is flexible, there aren't two similar Scrum implementations. But dropping a part of the framework is not the same as being flexible.
1 I often introduce the Shu Ha Ri progression model (that roughly means learn - detach - transcend) for agile adoption. From the C2 wiki:
As the beginner starts to learn, Shu gives them structure. It forces them to adhere to the basic principles (...). Since the beginner knows very little, they can only progress by slavishly adhering to these principles (...).
As the beginner gains experience, they naturally will wonder why?, how?, is there something better? Ha... the separation (much softer word than break) is the experimentation done around the principles... first straying only a little and then more and more as these ideas are tried against the reality of the world.
As the experiments of the Ha stage continue, bit by bit, the successes are incorporated into daily practice... we look for opportunities and use the patterns we have learned and tried out that closely fit those opportunities. This Ha/Ri stage is what makes an art the 'property' of the practitioner rather than the teacher or the community. Eventually, you are able to function freely and wisely.
I'm certainly not saying that one must stay at the Shu phase (the goal is beyond the first level), what I'm saying is that learning new ways of working takes time, don't ignore practice. As Ron Jeffries once said "They're called practices for a reason... You have to have done them. Practice makes perfect."
Update: (answering a comment)
One of the decisions we would like to take is the role of each person in the 'Product Owner' team.
Just to be clear: there should be only ONE Product Owner. He can of course work with a team but, still, there should be a single authoritative voice for the team. If I rephrase, there is no Product Owner Team.
For ex: What would the role of a technical person be?
Well, for me the technical person has no role to play in this team (unless he is there to train or support people at writing stories but the ScrumMaster should typically do that). Writing stories means capturing the essence of business oriented features, there is no real need for a technical point of view at this stage. Technical complexity (or even feasibility) will be included later in the estimation.
It seems to me that the end result of the requirements phase would be user stories that the developers will use in the iterations. Will the technical person be estimating the tasks? Traditionally, we've had the programmers estimate their own tasks
People doing the work should estimate the work (you can't expect a team to commit on something if someone else estimate the work for the team). In other words, the team should estimate stories. On top of that, experience shows that 1. collective estimations works better than individual estimation 2. we are better at doing relative estimations. So my recommendation would be to estimate the size and complexity of stories relatively using story points/t-shirt size/unit-less points and to do collective estimation during planning poker sessions. This worked very well every where I used this.
One of my colleagues (I work for a company which consults in agile working) has written several blogs about this separation between the requirements gathering and the development process. He describes how this can work very well in practice.
So far I have had experience with hybrid models only :-) None of the agile projects I have worked on so far implemented any Agile methodology strictly by the book. You needn't either.
The point is, any methodology is just a starting point / a collection of ideas you can use to work out your own process, tailor made to the specific project, team and circumstances.
Start with a process which looks good to you, then see how it works in practice. Keep regular retrospectives at the end of each iteration to assess how things are going, what worked in the last iteration and what didn't, and how could you improve things further. Then implement the most important ideas in the next iteration. In other words, develop the development process itself in an agile way :-)
Update: anecdotes about the requirement process
As I write this, I realize you may not got much useful info out of it... but at least it shows you that projects and processes vary a lot.
In one project, we had a fairly strict Scrum process, with a product backlog, although we didn't have a real customer: the product was new, and the prospective users didn't yet know it existed. Also it was a fairly specific and standardized domain where our company had a lot of experience. At the time I was part of the team (this was before the first release) we didn't really have much formal requirements gathering, because much of the key requirements were imposed on us by a standard. On top of that, we had some of our own ideas how to make the product stand out of the crowd.
In another project, we loosely had a Scrum process, but our sponsors and users did not really know about it, so we were struggling quite a bit. The "requirements gathering" was rather informal in that the product was huge and different people / subteams were assigned to different areas, working fairly independent of each other. Each subteam had their own contact(s) to discuss the requirements with, and the contacts were geographically separated - we rarely saw any of them face to face, so most of the communication happened via email, using lengthy Word docs. To top it off, we had a team of domain experts, who were often in wild disagreement with the users regarding the concrete requirements, however they were not very communicative. So the requirement process often consisted of reading lengthy documents containing obscure mathematical stuff, then other lengthy documents containing GUI requirements, then trying to figure out how to bring the two together... then discussing the requirements with the domain expert who briefly announced that it was a piece of sh*t, and we tried to tease some more useful and concrete improvement ideas out of him... then rewriting the requirements doc according to our latest understanding and the expert's comments, and sending it back to our contact person... then repeat from square 1.
In our current project, we again have many users scattered around a large part of the globe. However, at least our IT management is more knowledgeable about SW development and agile processes. We work on a large legacy system, which was in a pretty bad shape a couple of years ago - so maintenance and stabilization is a large part of our day to day work, and new requirements take less than half of our time on average. When we have one, though, we usually have preliminary estimation meetings where we try to come up with a crude estimate on how many person-days this project going to take. Then later our business analyst works out more and more details with the stakeholders, and our team works on filling out the technical details.
It seems to me if you label business analyst, subject matter experts, technical person and a user interface person as "the product owner" team, you really haven't deviated from "pure" agile.
That said, "pure" agile is somewhat of a misnomer because most agile advocates will tell you that the #1 or #2 selling point is its ability to adapt to the business processes and corporate culture of your existing organization.
The critical success factor might be having that product owner team, and all stakeholders really, invest in participating in some of your dev team's agile processes (showing up for demos, being accessible for questions during the sprint, etc).
Edit:
This quote from Wikipedia documents the very simple role of the Product Owner:
The Product Owner represents the voice of the customer. He/she ensures that the Scrum Team works with the “right things” from a business perspective. The Product Owner writes customer-centric items (typically user stories), prioritizes them and then places them in the product backlog.
Scrum isn't meant to enforce processes on how the Product Owner gets their job done. It's only the interface between the Product Owner and the Team (sprint planning and sprint review) that Scrum tries to outline.
Could we call this, "Building the back log," as that is really what this is, to my mind? The idea is to get those top priority pieces and then work from there. I have seen a few different Agile processes and some worked better than others but the key is how well is the buy-in from those involved in the process.
I'd also agree that 1 month is too long for a sprint. 2 week sprints seem about right to my mind though I have seen slightly longer and shorter sprints that also work. Another question is how big is the team and projects that are being done as stuff that may take years may not be easily done. I say this as someone that survived a project that lasted over a year and many sprints and demos later finally finished the project successfully.
I'd likely consider the technical person being the one that has to keep an eye on the big picture and understand what may be reasonable to do and what is unreasonable to do,e.g. having the system read my mind to know what I want done before I wake up in the morning without my having to write out anything other than simply thinking it would be unreasonable. Don't forget that the stories will develop into more cards as the stories are just a high-level view of what the end result is, which usually doesn't cover how easy is it, how much time will it take and a few other aspects.
For the sprints themselves, developers should estimate how long it takes to do various tasks. Determining the priority of stories though isn't part of what the developers do though. The requirements gathering session could also be seen as building a project charter so that there is a timeframe for the project as a whole, objectives and other high-level details that should be stated at the beginning.
I work at a company with hundreds of people writing software for essentially the same product. The quality of the software has to be high because so many people depend on it (not least the developers themselves). Because of this every major issue has resulted in a new check - either automated or manual.
As a result the process of delivering software is becoming ever more burdensome. So that requires more developers which... well you can see it is a vicious circle.
We now have a problem with releasing software quickly - the lead time even to change one line of code for a very serious issue is at least one day.
What techniques do you use to speed up the delivery of software in a large organization, while still maintaining software quality?
I also work in a large and cumbersome organization. I've had success implementing several agile software development methodologies, but there are two in particular that I have found especially valuable.
Iterative and incremental development - Keep your release cycle short and tight. Across a large team, if numerous changes are made in between releases, you can find yourself in an integration nightmare.
Large organizations lean towards big project plans with lengthy development time lines. Fight this. Planning a project out an entire year makes no sense when your whole perception might change after the first two weeks of development. Condition your stakeholders to get used to the idea of making small incremental releases and adapting to ever-changing requirements.
Automated Unit Tests - This is a great way to insure you are releasing quality software. The worst bugs are caused by seemingly innocent code changes that have unintended consequences elsewhere. Comprehensive unit tests are maybe the best way to catch this kind of bug. If you can graduate to test driven development or behavior driven development, even better.
Any large organization is going to have some mediocre developers. It's a fact of life. Automated unit testing is a great way to keep an eye on them. Have one of your better developers write their unit tests for them. You will have assurance that at least their code works (even if it's ugly).
See Continuous-Integration
And please read The Joel Test: 12 Steps to Better Code.
There are many ways to improve the process, but the key component is modularity. By clearly separating responsibilities (both in code and in the organization) and defining clear and consistent interfaces, one large team can work as many small teams all tied together.
Wise but gloomy sayings:
Fred Brooks: Adding programmers to a late project makes it later.
Gerry Sussman: Programmers combine like resistors in parallel.
Somebody else: The cost of a project is the number of programmers times the length of the schedule.
Something that might work:
Organize the project so that there is a core application built by one or two people, preferably operated via a language. Then let all the programmers effectively be users of the core, by coding in that language.
I'm thinking of language-based products: SAS, S/R, MATLAB, etc.
Should developers be limited to certain applications for development use?
For most, the answer would be as long as the development team agrees it shouldn't matter.
For a company that is audited for security certifications, is there a method that balances the risk of the company and the flexibility, performance of the developers?
Scope
coding/development software
build system software
3rd party software included with distribution (libraries, utilities)
(Additional) Remaining software on workstation
Possible solutions
Create white-list of approved software where developer must ask for approval for desired software before he/she can use it. Approval would be based on business purpose/security risk.
Create black-list for software. Developers list all software used. Review board periodically goes over list.
Has anyone had to work at a company that restricted developer tools beyond the team setting? How did they handle the situation?
Edit
Cleaned up question. Attempted to make less argumentative.
Limiting the software that developers can use on their work machines is a fantastic idea. This way, all the developers will quit, and then the company won't have to spend as much money on salaries and equipment, resulting in higher profits.
Real answer: NO!!!
No, developers should not be limited in the software they use, because it prevents them from successfully doing their jobs. Think about how much you are paying your team of developers, - do you really want all that money to go spiraling down the drain because you've artificially prevented them from solving problems?
1) Company locks down the pc and treats the developer as competent as a secretary
What happens when the developer needs to do something with administrative permissions? EG: Register a COM object, restart IIS, or install the product they're building? You've just shut them down.
2) Create a white-list of approved software...
This is also impractical due to the sheer amount of software. As a .NET developer I regularly (at least once per week) use upwards of 50 distinct applications, and am constantly evaluating newer upgrades/alternatives for many of these applications. If everything must go through a whitelist, your "approval" staff are going to be utterly swamped by just one or 2 developers, let alone a team of them.
If you take either of these actions, you'll achieve the following:
You'll burn giant piles of time and money as the developers sit on their thumbs waiting for your approval team, or doing things the long slow tedious way because they weren't allowed to install a helpful tool
You'll make yourself the enemy of the development department (not good if you want your devs to actually do what you ask them to do)
You'll depress team morale substantially. Nobody enjoys feeling like they're locked in a cage, and every time they think "This would be finished 5 hours ago if only I could install grep", they'll be unhappy.
A more acceptable answer is to create a blacklist for "problem" software (and websites) such as Pidgin, MSN messenger, etc if you have problems with developers slacking off. Some developers will also rail against this, but many will be OK with it, provided you are sensible in what you blacklist and don't go overboard.
I think developers should have total control on applications that they use as long as they can do their job with them. Developers' productivity is directly related to working environment and no one will like being restricted and everyone likes to use software they like themselves.
Of course there should be some standards in terms of version control, document format, etc., but generally developers should have right to use any programs they want.
And security should be developer's concern - company admins should care about setting up proper firewall to protect against any kinds of attacks.
A better solution would to create a secure independent environment for the developers. An environment that if compromised won't put the rest of the company at risk.
The very nature of the development is to create crafty ingenuous pithy solutions. To achieve this, failures must happen.
Whatever they do, don't take away the Internet in general. Google = Coding Help 101 :)
Or maybe just leave www.stackoverflow.com allowed haha.
I'd say this depends on quite a list of factors.
One is team size. If you have a team of half a dozen developers, this can be negotiated whenever a need for some application pops up. If you have a team of 100 developers, some policy is probably in order.
Another factor is what those developers do. If they compile C code using a proprietary compiler for an embedded platform, things are very different from a team producing distributed web or PC software in a constantly shifting environment.
The software you produce and the target customers are important, too. If you're porting the Linux kernel to some new platform, whether code leaks probably doesn't matter all that bad. OTOH, there are a lot of cases where this is very different.
There are more factors, but in the end it all boils down to two conflicting goals:
You want to give your developers as much freedom as possible, because that stimulates their creativity.
You want to restrict them as much as possible, as this reduces risks. (I'm talking of security risks as well as the risk to ship non-functioning software etc.)
You'll have to find a middle ground that doesn't hurt creativity while allowing enough guarantees to not to hurt the company.
Of course! If you want a repeatable build process, you don't want it contaminated by whatever random bit of junk a programmer happens to use as a tool to generate part of the code. Since whatever application you are building lasts much longer than anyone expects, you also want to ensure that the tools you use to build it are available for roughly the same duration; random tools from the internet don't provide any such gaurantee.
Your team should say "The following tools are allowed for build steps and nothing else" and attempt to make that list short.
Obviously, it shouldn't matter what a programmer looks at to decide what to do, so the entire Internet is just fine as long as its just-look. Nor does it matter if he produces code by magic (or random tool) as long as your team doesn't mind accepting just that tool's output as though it were written by hand.
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'm wondering what you do as a programmer that's not programming but necessary for your task (eg: local setup, server setup, deployment, etc). I'm curious to know how many non-programming related tasks people are performing.
For example, when on web development projects I often:
Install servers
Manage user right/access to servers
Perform backups
Configure IIS/Apache
Setup FTP sites
On non-web projects I often:
Write build scripts
Setup source code management tools/procedures
Probably more stuff I'm not thinking of
Some tasks are more related to programming than others (such as writing build scripts) but others fall outside of my area of expertise (domain setup comes to mind). Just interested to know how many people perform tasks in their jobs that are not programming related.
The sad reality is that non-technical people look at technical people and expect them to know everything that is technology related, not understanding that there are specializations within technology which we might know nothing about.
I often think it is very much like a doctor that specializes in a particular discipline. All doctors have a baseline of knowledge in the medical field, but will not know the specifics of other specializations (a cardiologist will not know as much about anesthesiology and vice versa).
So while I think it is unreasonable for people to expect technologists to know everything, I do think that it is reasonable for them to expect that we know something when it comes to technology.
I think a more important facet of this question is how much one is expected to know about the specific domain where they apply their skills (finance, manufacturing, etc, etc). I think that is incredibly important, as having that domain knowledge makes them much more valuable as a programmer, as they can understand the problems on a deep level, and as a result, provide more comprehensive solutions for them.
Expected? Almost nothing, but everyone's always really happy when you know more.
The more you know outside the narrow confines of programming, the more valuable you are to your employer.
Things that have come up for me:
requirements gathering
writing use cases
evaluating test plans
negotiating with vendors
tax law
revenue recognition rules
ideas about how users behave
basic economic theory
usability guidelines
differences in consumer behavior in different countries
system administration (being a full on sysadmin)
database configuration, optimization, setup (basically being a DBA)
monitoring systems
networking principles and techniques (you'd be amazed how handy a packet trace can be when debugging something...)
being able to evaluate a business plan written by someone else
image manipulation
how to diffuse a situation and avoid arguments
how to corner someone and make them to commit to something when they don't want to
how to choose battles
I think the non-programming skill I use the most in my programming job is writing. It's really crucial to be able to explain ideas, designs, algorithms, and so on, and you can never count on being around to do it in person (or having the time). I spend a good amount of time at work writing up design documents and other documentation so other engineers can get their heads around my code and algorithms. So I'm really thankful that I had good writing classes in school and can put a sentence together. :-)
Probably depends on the size of the company you work for. As someone who has worked mainly at small to medium sized businesses, I've also been responsible for:
database creation, management, and tuning
supporting the internal applications I launch
managing website certificates
setting up external hosting
and I'm sure there's more as well
Well, since a programmer's primary tool is his computer, I think it's fair to assume some expertise with it. Most of those sorts of things you've described are difficult for someone unfamiliar with computers, but pretty easy (even with little prior experience) for someone who understands the domain and knows how to find and read documentation.
In a big, well-organized business or project, I'd expect someone who was more specifically familiar with those sort of administrative things to take care of them. However, if there's not enough of them to warrant a full-time job, then I don't think it's unreasonable to have anyone competent work on it; and programmers are probably at the head of the queue in that regard.
I find the vast majority of "bugs" discovered by users are configuration problems with the systems on which the application is installed. Having developers that understand the common machine and network setup errors is very desirable.
For example if an application sends email as part of its operation its useful to have developers knowledgable in DNS and SMTP configuration.
Of course it depends on your size of business, large organisations can probably shield developers from this by using other specialists.
I realized I'm never hired for the actual job, but as a problem solver. Whether I figure out what's going on, and fix it through code, or software, or something on the network, this seems to be the main perception of what clients want.
This will vary greatly depending on where you are. I've worked with people who know none of this stuff, and people who are experts.
Knowing this will help you greatly. In general it's always better to understand the environment your code is running in. Not understanding the context leaves you somewhat helpless.
Additionally there are often bugs that are not code related but configuration related, for example a page not showing up because of the apache configuration. You're very handicapped in debugging if you don't understand the environment.
People around a work place probably expect a programmer to be their IT HelpDesk guy... it happens around here to me. argh.
Where I work, all developers are expected to be able to use Subversion and have to be able to setup and configure Apache and Tomcat on their PC.
The biggest challenge is not the technical issues associated with getting the environment up and running but the domain knowledge required to effectively develop software in a small shop. For me, I work on a lot of different projects from a variety of sources in a mostly isolated development environment. This means that I need to come up to speed on the domain of the project pretty quickly in order to be effective in developing a solution. In the past I've worked on print accounting solutions, active directory management, research survey databases, and currently a quasi-CRM solution for a charitable organization. I wish I only had to know the nuts and bolts of setting up my development and build environment.
It often depends on the size of the company. In a little company, you have to know how to do everything, including systems admin, and network admin, even if your job is focused on programming.
In a big company, you get to see a little slice of the universe, and they often don't like you peeking outside of your box. Not only do you not need to learn everything, they're often unhappy with you if you try.
However, the more you understanding about the machines, how they work, and how they function in an operational environment, the easier it is to diagnose problems and write better software. The more you understanding about the domain you're writing applications for, the better you are able to differentiate between the users needs and their desires.
One of the coolest things about being a software developer is you have a life long excuse for sticking your nose into both the technologies and the various business domains. If you've shifted around to a few different industries, you tend to become loaded down with all sorts of interesting tidbits. There is always more to learn ...
Paul.
It's good to expose yourself to other technologies, but I really think it's a bad idea for you to not fully disclose the fact that you aren't experts in those areas (esp. domain setup). I've worked with people who thought they could do it all but ended up doing those tasks so poorly that with all the time (and money) they've spent trying to get it right, a consultant would have been paid for several times over.
I've worked at a company where I was responsible for everything "related to a computer" including the domain, PCs, database, custom software, builds, MS Office, PowerPoint, Quickbooks...; a mid-size company where it was development and builds; and a large company where I focus solely on the .Net code for my project (someone else handles the database and another handles reporting).
The mid-size company has been the best experience so far (pretty new at the large company) where I was given enough responsibility to feel useful and had easy access to everyone else to ask questions about those other tasks.
You are not alone out there. The position I signed up for was "ASP.NET Web Developer"... However, my job consists of:
Windows Server Administration
Limited Linux Administration (running
top to monitor CPU utilization and changing apache configs)
LDAP Administration / Tuning
MS SQL Server 2005 Administration /
Tuning
Database Development
Crystal Reports Developer
Perl Scripts
C# Win32 Developement
C# / ASP.NET Web Developement
Managing User Access Rights for
Windows Servers
Limited Network Troubleshooting
Being in a company that is constantly striving for supreme "Operation Effectiveness" my task list only grows by the day. I did not make up that list either. All of the items mentioned above, I have either touched or supported in the past 3 years I have worked in this company.
That being said, in a good development shop, you should have one specific task. As the saying goes, Jack of all trades ... master of none.
This depends greatly on what you're programming. If you're doing low level device drivers, it's vital that you understand the underlying hardware. If you're doing a standalone Java app, the better you understand the JVM and libraries you're using, the better - but it isn't strictly necessary to know a lot.
In general, the more you understand about your system environment, the better. How much your peers and management expect you to know depends on them.
Ignorance will, eventually, be punished. If not by your peers and management, the world will do it. Check any week's headlines or RISKS digest for examples where ignorance of the system environment cause software failure.
[rant mode on]
Ha, the curse of Excel and Word.
Outside work - particularly friends and family but sometimes when consulting or delivering software too, any and all non-technical people expect you to understand these. There's that internal groan when someone asks you across to have a look at a small problem they're having with some facet of Office. And because it's a client and you want to appear helpful you agree.
There's just this blanket expectation that because you're a developer you have an innate knowledge of configuring spreadsheets, fixing Word templates, and any and all other office techie tasks, and furthermore you can cast your eye over some badly configured Office mess and instantly diagnose what the problem is.
I can only just about manage to put together a spreadsheet to schedule my reoccuring invoices and set up a Word template to write them. I regularly tell people that too - but no-one ever listens.
It depends a lot on the type of software you're currently developing
For example, when I was working on software for a local government, I had to learn things like
What are the rules for registering animals (pets). What are the types of registrations, what discounts apply, what are penalties for not registering on time
How are council rates calculated. How are rates raised yearly (actually, the algorithm for raising yearly rates and its implementation was the most complex task I met so far).
How are building permits issued. What types of inspections can be performed. Who is involved in the process of issuing a building permit (owner, builder, architect, officers etc.)
How often are water meters read. How are water meters assigned to properties, how many dials are on a water meter, how to detach a water meter from one property and to attach to a different one
What are different pension types. What are different discounts that are granted depending on a pension type.
What are different types of receipts. What different types of terminal printers (those that are used to print small receipts) exist and how to print to them.
What are properties, strata children, what are rules for dividing properties into 'parcels' ...
Well, that's just part of non-programming stuff that I learned during the 2 years on the project. The most unfortunate thing here is that now that I moved to a different company, there is very little chance that any of this knowledge I will ever use.
My job title is "Senior Software Engineer". In point of fact, for most of the past several years, I did fairly little software development, but did do a lot of:
Systems & web administration
Static web page development with HTML (I don't consider that programming, although I have done PHP, CGI, and JavaScript).
As others have said, help desk sorts of stuff, although not as much as in the past.
As a "task leader", I'm expected to have some people/management skills, although that usually devolves to writing monthly reports. I also get sucked into CMMi stuff from time to time, which in an ideal world might be somewhat relevant, but is usually just record keeping so the employer can bid on new contracts which require it.
Working in science lab, there's a need to know some of the science, especially if you want/need to work on the code doing the scientific calculations.
Working in a (U.S.) government facility, there's lots of paperwork and a need to know lots of government regulation (e.g. Freedom of Information Act)
Fortunately, I've recently made an internal transfer where I'm doing more development work and less of this other stuff!
Personally, I find that knowing more is always good, it paves the way to the next level. The hardest things in life is at the integration point. Literally. People focus a lot on specializing, but don't forget that you need people who can straddle both realms.