Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm working in a small company, started as a developer and coded pieces of a big system being provided with detailed specs. Over five years I moved towards analyst position. I know how existing parts of the system are build, so when we need a new subsystem I know how to connect it to the existing things. So I analyse requirements for a new subsystem to be done, design a new module, then code main parts of it. After that me with my colleagues who are proper analysts write detailed specs for junior developers to finish the module.

The problem is that I don't see a new job for myself. I realise that jack-of-all-trades isn't considered to be good, and I don't see getting myself a job exactly like this in a big company. But if I look for a developer job, then I would be somewhat like junior again? Because if I will be provided with detailed description of what software has to do, all that seems to be left for me is merely translating spec to the code, which is plain boring. But developer is considered to solve problems, so which problems are those supposed to be? Only pure technical problems I can imagine is performance optimization.

So basically my question is - what problems developers are supposed to face and solve, if all decisions of how application should work to meet customers needs are considered to be an analyst job? What problems do you solve at work?

share|improve this question
Developers still translate the information in a spec to code and often solve a myriad of other problems along the way. We don't even use analyst at our company and we are quite successful as it stands. –  Akira71 Dec 8 '12 at 0:10
err...write the code? –  Rig Dec 8 '12 at 1:43
A spec answers the 'What' question (what shall the software do?). From this, the design aims at anwsering the 'How' question (how to create and organize classes for making the software work as intended)?. Finally, coding fills the holes in the design and demonstrates in which ways the spec was incomplete or wrong. –  mouviciel Dec 8 '12 at 9:34
@mouviciel Maybe I'm yet to see the spec that is all about 'What', and it doesn't contains any assumptions about 'How', such as supposed interface, for instance. –  Leeho Dec 8 '12 at 9:46
@Leeho - There are several levels of specs. If interface is about how the system is split in modules and how these modules work together and thus appear to be design information, at the module level interface is about what the module has to expect as input and what it has to deliver as output and thus becomes a spec that the module has to conform with. –  mouviciel Dec 8 '12 at 9:59

4 Answers 4

One of the Great Myths™ of programming is that there are clear lines drawn between Architect // Designer // Programmer // Coder. This was, and is, bollocks. The process begins with the customer saying, "I need ..." and ends with them saying, "Yes! That's what I wanted!" And you don't get to the end without a lot of tweaks / changes / massive-rewrites of the spec.

The Devil is not in the details, it's in the coding. All kinds of lovely assumptions die the Big Death when put up against the reality of ... reality. This is where you find that not all time zones are a multiple of 60 minutes from UTC, that the sales tax in Sebastopol (city) is not the same as Sebastopol (county), that there are N>1 spellings of certain names (people, cities, whatever), you can ship melatonin anywhere in the US, but doing that in the UK will get you arrested, etc., etc., etc.

Having the spec "done" means you have just begun on the journey. One of the many lovely surprises ahead is that when you deliver a product that exactly meets the spec as written, the customer will say, "... uh, well, what we really wanted was ..." Such is life.

This is one of the reasons that agile development tries to release useable code every 2 weeks or so. The user is continuously forced to reconcile what they asked for with what it actually looks like in real life.

I believe it is true that any architect/designer that is also not part of the coding team is too distantly removed from the process to be of any real use. And I say this based on a lot of experience.

share|improve this answer
I'm sorry I cannot upvote this answer more than once. Something like 10k upvotes would have been adequate... :-) And, thanks for the link to Wikipedia. I always wondered how to render the italian term "coglionata" in english and now I know it. –  AlexBottoni Dec 8 '12 at 8:24
Aren't those assumptions just mistakes made by analyst? We have tests and QA team to find our bugs, but I can't make myself fully agree with idea that developer is supposed to do the same for analysts. –  Leeho Dec 8 '12 at 9:43
@Leeho - perhaps - but in reality not. The analysis can be correct from the information given but still produce a system with flaws. This is due to the "missing" information and it's no one's fault that it happens. –  ChrisF Dec 8 '12 at 10:04
"I believe it is true that any architect/designer that is also not part of the coding team is too distantly removed from the process to be of any real use. And I say this based on a lot of experience.". Too true. –  Shivan Dragon Dec 8 '12 at 14:47
+1 "All kinds of lovely assumptions die the Big Death when put up against the reality of ... reality." –  Michael Shaw Dec 8 '12 at 16:23

I believe this way of working is on the way out. Analysis is a (developer) task not a role.

Gathering requirements and formulating a spec for a junior to execute is a myth. Programming is a lot more then 'just typing it in'.

Perhaps you can spend your time tutoring these poor juniors who have to try make deadlines with these 'specs'. Hey they just need to type it in. How hard can that be?

share|improve this answer
This way of working goes back to the 50s and 60s when most applications were coded in assembler, and translating a super-detailed pseudocode spec into actual code was still a nontrivial task. –  Michael Borgwardt Dec 8 '12 at 9:09
They don't have to try to meet deadlines, actually. And usually they go way faster than me, cause I try to make complete descriptions and I'm there to answer all the questions, which harms my own coding, but it's the different issue. What I also do is that I think of interesting tasks to enrich the system and fetch those to people who got bored with endless "make a new form that provides customer with the way of input those and those", when database classes are already done, form detailed description is provided, and our framework dictates all other code structure. –  Leeho Dec 8 '12 at 9:57

I have the full specs finished for a ladder to the moon; the height, number of steps, what color etc are all specified - now it just needs implementing.

share|improve this answer

Just to add some practical guideline to what already noted by others...

Having a solid experience in analysis, design and project management is a very good thing in any case. What you can do to improve your CV is:

  1. Improve and refine your existing project management skills. Managing a project is a discipline in itself and is always in demand. You can read books, take classes and, maybe, take some certification. This would allow you to leverage in the best way your existing skills.

  2. Improve and refine your knowledege of some language, platform or framework you are using. If possible, take a certification on it. This would allow you to demonstrate you are particularly strong in a specific field (that is what you seem to lack mostly, accordingly with your own description).

  3. Extend/widen your knowledge to some new language, platform or framework. This would increase the probability to meet the requirements for a new job.

My very personal suggestion would be to develop a deep knowledge of a specific platform/framework and its related language (e.g. Java/Android, Ruby/Ruby-on-Rails, KDE/Qt/C++, etc.), if possible focusing on a specific type of end-user problem/solution (for example social networking in Rails, mobile interfaces to web app/service with android, healt-management solutions in C++ for the desktop, etc.).

Even better if you can consolidate such skills in a small/medium size personal project to be used as a demo (quite often an open source project).

This because companies often hire people that represent for them a solution to a specific platform/framework/domain-related problem. It should not be so (they should just hire good programmers...) but this is often what they really do.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.