Related
i just joined this new group and basically haven't even really done any heavy lifting development but just some basic web store migration stuff. and i've been given the challenge of coming up with improvement areas for the development process. I'm thinking of using Joel's list as the basis for determining what can be improved in my team, and besides that perhaps ask few of my seniors there who have been around for a while.
i'm not exactly sure why i was given this but i'll take it on anyway as it sounds like a good challenge. but what other tips or resources that you would advice me on how to do this properly.
P.S: i have about two weeks to do this, thus please suggest something practical and nothing to big as it's just lil ol me who has to do this within this time frame. :)
thanks
Having been in this tricky position a few times let me give you one piece of candid advice.
The person who gave you this task almost certainly has an idea in mind, and they would like you to reinforce that idea.
How you react to this is up to you and the environment in which you work.
I think you'll probably have to start by finding out where the major weaknesses are. Given your time-frame, you'll have to focus on the a few of the major issues.
Try and find out where time is being wasted. Interview your colleagues, customers, etc to try and find out where the pain is being felt. Observe the team at work and try to identify areas of inefficiency.
You'll probably find people are more receptive to your recommendations if you focus on the immediate problems, as opposed to coming at them with a range of good practices.
Once you've identified a few problem areas you'll be able to research some possible solutions in depth. Without a tighter focus, you'll be swamped by the different possibilities. And, in practice, you'll probably need to introduce new initiatives gradually anyway, which will involve you reviewing the next steps incrementally.
In order to decide what to improve you have to take into account the current status (obviously). Try to find "pain points" - the things that cause grief to the developer's while doing their job:
Do they have proper tools?
Are they fully aware of the current development goals?
Do they have an optimal development environment?
Are you using Agile/TDD/Pair programming?
I've choose the points above because they can be fixed easily in two weeks.
You've been working in this company for enough time to come up with several points of improvement, also talk to the other developers to find out what they think could improve their work.
Whatever you decide remember that your goal is to improve the development process for the dev team but also for the end customer - think on how you can provide high quality software in less time (within budget).
Since most humans come with a brain, teams usually already know what the problems are and how they can be solved. Only, there is a reason why the situation is like it is and there are forces which actively prevent change.
So just ask them what needs to be done and then find out a way how you can either do it or talk them out of 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 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.
I have been offered by my employer to work on SAP Business Objects to analyse large amount of data they have.
I have the following doubts before I could accept that:
a. I love programming and do not want to lose touch with it. Do you think working on this tool would excite a person who loves building software? Or Is it like most part of the tool configurable through Wizard like interface?
b. Is this tool capable of working on data collected for research and testing purpose?
I tried googling but all I could get is some videos which mentions "Business Intelligence" more than 12 times a minute. Any suggestion or even links to help me make the preliminary analysis would be helpful. Thanks...
Business Objects is not rocket science. A competent developer should be able to figure out how to build a universe in a few days. My first experience took me about two days to figure out how to build a universe and another two days or so to get some analytic reports out of it.
However, 'research data' suggests that the actual structure of the data will vary depending on the nature of the survey so you will probably find yourself constantly making ad-hoc changes or new bespoke universes for each job. Business Objects is probably a reasonably flexible way to do this (a custom universe for a tabular set of research data could probably be set up in a few hours). However, the job would basically devolve to a reporting analyst position.
If you're not a 'tools guy' by nature you will probably find this sort of work unsatisfying. I do full life-cycle work on data warehouse systems and from time to time this involves developing front ends using Business Objects. I'm quite happy to work with it casually as part of a larger job but I wouldn't want a job solely working with just one reporting tool.
If you think of yourself as a programmer I would recommend against accepting the job if it was limited to just working with Business Objects.
I have experience working with Designer and reporting in Business Objects... Honestly, it's quite easy. I have to say I'm a total programmer at heart, and absolutely hate working with it, but that's what possessed me to write a program that uses the DLL's to automate everything. I enjoyed automating it, and ended up making a program that did in about 5 minutes what it previously took me weeks to do. Now all the BO developers use it, and I mostly spend my time updating that.
In summary... It sucks to work with when it's +60% of your job, but you don't have to lose out on Programming. If anything, I think I've improved my programming. Now I barely do the crappy side of the work. I just run my program, and everything works out.
I'm not sure what you are asking in question "B".
I'm looking into using log shipping for disaster recovery and I'm getting mixed messages about whether to use the built-in stuff or roll my own. Which do you recommend, please, and if you favour rolling your own what's wrong with the built-in stuff? If I'm going to reinvent the wheel I don't want to make the same mistakes! (We have the Workgroup edition.) Thanks in advance.
There's really two parts to your question:
Is native log shipping good enough?
If not, whose log shipping should I use?
Here's my two cents, but like you're already discovering, a lot of this is based on opinions.
About the first question - native log shipping is fine for small implementations - say, 1-2 servers, a handful of databases, and a full time DBA. In environments like this, the native log shipping's lack of monitoring, alerting, and management isn't a problem. If it breaks, you don't sweat bullets because it's relatively easy to repair. When would it break? For example, if someone accidentally deletes the transaction log backup file before it's restored on the disaster recovery server. (Happens all the time with automated processes.)
When you grow beyond a couple of servers, the lack of management automation starts to become a problem. You want better automated email alerting, alerts when the log shipping gets more than X minutes/hours behind, alerts when the file copying is taking too long, easier handling of multiple secondary servers, etc. That's when people turn to alternate solutions.
About the second question - I'll put it this way. I work for Quest Software, the makers of LiteSpeed, a SQL Server backup & recovery product. I regularly talk to database administrators who use our product and other products like Idera SQLSafe and Red Gate SQL Backup to make their backup management easier. We build GUI tools to automate the log shipping process, give you a nice graphical dashboard showing exactly where your bottlenecks are, and help make sure your butt is covered when your primary datacenter goes down. We sell a lot of licenses. :-)
If you roll your own scripts - and you certainly can - you will be completely alone when your datacenter goes down. You won't have a support line to call, you won't have tools to help you, and you won't be able to tell your coworkers, "Open this GUI and click here to fail over." You'll be trying to walk them through T-SQL scripts in the middle of a disaster. Expert DBAs who have a lot of time on their hands sometimes prefer writing their own scripts, and it does give you a lot of control, but you have to make sure you've got enough time to build them and test them before you bank your job on it.
Have you considered mirroring instead? Here is some documentation to determine if you could do that instead
If you decide to roll your own, here's a nice guide.
I'm assuming you're going this route because Enterprise Edition is so costly?
If you don't need a "live-backup", but really just want a frequently updated backup, I think this approach makes a lot of sense.
One more thing:
Make sure you regularly verify that your backup strategy is working.
I'm pretty sure it's available in Standard, since we're doing some shipping, but I'm not sure about the Workgroup edition - it's pretty stripped down.
I'm always in favor of the packages solution, but mostly because I trust a whole team of MSFT developers more than I trust myself, but that comes with a price for sure. I'd second that any solution you roll on your own has to come with a lag notification piece so that you'll know immediately if it isn't working - how many times do we only find out backup solutions aren't working when somebody needs a backup? Also, think honestly about how much time it will take you to design and roll your own solution, including bug fixes and maintenance - can you really do it more cheaply? Maybe you can, but maybe not.
Also, one problem we ran into with Workgroup edition is that it only supports 5 connections at once, and it seems to start dropping connections if you get more users than that, so we had to upgrade to Standard. We were getting ASP.NET errors that our connections were closed if we left them unattended for even a few seconds, which caused us all kinds of problems.
I would expect this to be close to the last place you'd want to save a few bucks, especially given the likely consequences if you screw up. Would you rather have your job on the line? I don't even think I'd admit it, if I felt I had a chance of getting this one right?
What's your personal upside benefit in this?
I tried the built-in log shipping and found some real problems with it so I developed my own. I blogged about it here.
PS: And just for the record, you definitely get log shipping in the Workgoup edition. I don't know where this Enterprise-only thing started.
I work for a software vendor whose market is developer tools and we have been looking for a QA person for our products.
Since we are a small shop the position will be a combination of Support and QA however since we make developer tools, our support consists in large part of actual development (in that the person must read and understand our customers code and find and point out bugs in it).
The QA portion will also consist of writing applications (in a variety of platforms and languages) and testing how they work with our tools.
The main issue I am running into is when you tell someone with development experience that the position contains "QA" it its title (or even in the job description) they shy away from considering the job.
I'm very interested in feedback and suggestions for how I can find a good person to fill this job and ensure that they are happy doing it. Any ideas?
Money and responsibility.
The reason I shy away from these types of jobs is they dont tend to hold my interest long enough. Having real development tasks should keep you out of that category. The other problem is the salary is usually significantly lower with that in the title.
I am a developer, but spent time working as a QA person (test writing, automation, tool writing/coding). I saw it as something I was doing on the side, and would eventually move out of.
The main reason I wanted out was that it simply was not the career I wanted. No amount of money/responsibility would change that. However I think respect has something to do with it as well. A lot of QA work is simply unappreciated, so that is something that would need to be clearly explained as "not how things work at your company."
I would find someone who wants a QA position, but has strong developement/coding/problem solving skills. They could fill in doing the tool creation or other small coding tasks, but it would be on the side. Sort of a reverse of my feelings above.
I think the ideal combination of jobs is product manager + QA. What I mean by product manager is someone who writes requirements documents and is responsible for making sure the product meets the requirements. This person would be a peer of the lead developer, not a superior. A person who is a developer but likes management and wants to take that career path might be very interested in that combination of roles.
To start with you can just take "QA" out of the title and description if that seems to be 'hot button' that is keeping candidates from looking at the position seriously.
From your description, your position doesn't have much in common with a traditional 'tester' role - the work is mostly writing and thinking about code, not banging on someone else's code and trying to break it. Think of it as a fairly eclectic, tools-oriented development position, and try to advertise and staff it accordingly. (And expect to pay accordingly as well - you get what you pay for.) There are quite a few developers out there who have good skills, but maybe a little shorter attention span than others, and who would prefer to work on a succession of mini projects rather than a longer-lasting piece of a bigger project.
You may just want to keep "QA" out of the title, and call the position "Developer Support" or something like that. Don't mislead any candidates about the duties of the role, but you can cast it more as a "You will be responsible for building the releases and ensuring they are ready to ship to customers."
Also make sure that there is a career path that leads into more development, not more QA, if that's what the candidate wants.
Finally, make sure that the other developers treat this person as a fellow developer, and not as somebody outside the team.
It's sad that "QA" has some stigma attached to it among developers, but it does.
I was a programmer working as a tester for a little time. If I may, the answer is quite simple: let them do whatever they want.
If you give them free reign, I can guarantee that your software will be tested in ways you never imagined.
If, on the other hand, you try to control such a person, then they will grow to despise you. This is inevitable.
The benefits outweight the costs. If you're a large corp then this decision is easy. Just hire software developers and tell them to "go to town" on your product. You'll love the results.
Money and responsibility are key, as Adam and Chops point out. Quality engineers should be on the same pay scale as the developers. Interesting work is also an important factor. The role sounds like a nice variety of tasks.
At my company, developers are often loaned to the test team between projects or when test team is swamped. Some have a knack, others don't. Still, most developers would rather test their own code than find bugs in others' work. The test managers actively woo developers with strong testing skills. I resisted switching to the test team for seven years. A promotion, a 20% raise and a promise that my role was primarily trouble-shooting, management and planning finally convinced me to switch. I do more hands on testing than I thought I would, but I get the challenging work too.
Pay comparable to development. Be truthful; disclose actual expectations of the role. Change the title to Software Quality Engineer.
I agree with Adam, money and responsibility are key. I would suggest that, if you're within a small company, that your QA team is small/non-existent. That probably means there's good opportunity for someone to come in and make a genuine effort to contribute and shape your companies QA policy, procedure and workflow.
Our company had a similar issue with QA, and we're still not there 100% with it. But giving the QA person the power to dictate policy and procedure, and participate in all aspects of product development so as to keep them in the loop has worked well for us. This means, when it comes to QA and testing, we've got someone who understands the product, knows it inside and out, has been heavily involved from the start, and has heavily shaped the procedures they themselves, and the development team, will follow. Responsibility is key.
Most developers are neither good testers nor do they enjoy testing, and you want someone who is both. Be honest in your job ad that the position is NOT a stepping stone to a developer position and you will have fewer applicants but a better chance of keeping who you do hire. QA typically has lousy pay, so if you are willing to pay better, you should be able to find someone. You won't keep them if you hire someone who wants to write code all day, regardless of how much you pay them.
I think you have a toughie here:
The cost of a full time developer for doing the job you require would be too high.
Most dev's (including myself) would get incredibly fed up, very quickly. Most dev's passion is coding, they want to do it as much as possible. Where TBH, from what you have said, it may be very little in the job role you have.
I would say perhaps look for a Junior, someone fresh with little experience. They will probably mould better to your testing/QA process, and it gives them a chance to start looking at production code, with perhaps opportunity to work with it.
Unless you are lucky, I would not expect a "developer" to stay for long, so either expect a bit of turnover, or possibly expand to a full dev role if required, and get a cheaper sole tester in.
I know you are a small shop, so finances may be a large part to play, but I would say you need to weigh up the possibility of getting a dev in and fixing the problems you have if they occur that often. Testers are cheap by comparison. May be best to get a tester in, find all the issues, then get a contractor/part time dev in to fix issues.
Dude, A certain company I work for has found the solution to your problems. Hire QE not QA. QA (Quality Assurance) does have a stigma to it. The job title itself implies boring rote tasks to most developers. QE (Quality Engineering) sounds just as bad, but doesn't scare off nearly as many people.
If all else fails just hire a developer. I mean seriously, you want someone who can write code, so hire someone who has training in that. The thing is, you need to look at your applicants and talk to them. You are looking for someone who knows how QE works and you want to hire a developer that works in the language your program uses not what it's written in.
The most common title for this posotion is "Software Developer in Test".
But I think another trouble is much more important - its hard to prevent a person with good testing and dev knowledge from migrating to Dev team