- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Get used to it.
My current project 11M lines of code, 100 interacting threads, multiple levels of abstraction through jump tables, no documentation, no support, on my own. Oh, and did I say that it is used in military aircraft control systems!
Admin
You will gradually get a hold of it. I don't know how, but if you want to, I can only advise you look at everything you can inside & outside the company.
And when you do understand an area, and everyone comes to you as the "expert", you won't feel any more comfortable than you do now....
Admin
Yeah, you'll never know the entire purpose, function and rationale of the system, but new hires should still get a one-hour crash course from the analysts on basic domain terms, like "originating" a mortgage, and the overall project plan, which you should have summarized for the original pitch already. From that point, figuring out what the code means becomes a lot easier.
Admin
Ignorance is bliss - enjoy it while you can.
Once you know the ins and outs, you become one of us...
Admin
I appreciate Alex's statements, but they don't address the actual question. Alex is talking about the breath-verse-depth issue when dealing with large systems. This question is about proper orientation.
Yes, any operation which is even close to properly run will have an orientation designed to inform the new employee of the information that they need to be able to figure out how to do their job.
No, there aren't very many operations which are even close to properly run.
Sorry kid.
Admin
With a gigantic system like that, there’s little a single person could do, but that's the whole point of the machine. The art of programming is taking a really large problem and breaking it down into a bunch of smaller problems. The big problem may be difficult, or even impossible to solve all at once, but the small problems can be easy. You've got a big problem- a system so complex you can't understand it, and nobody can help. So focus on smaller problems- understand one piece.
On a large team, you can only ever play a small role. Developers focus on small pieces of the puzzle, managers just try to keep the gears oiled and the team pointing in the right direction, and if everything fits together okay, you might get a decent product out of it.
As much as we joke about WTFs here, most WTFs arise from the same reality: the world is complex and modeling it in software is hard. Even the most simple business process quickly spirals out of control when you start looking at the exceptions and the edge cases.
Admin
My only level of input here is "I understand"... I am currently a SQL and Datamining guy, and the one big application my efforts support, my team doesn't actually use or know very well.
So when an end-user asks me to extract XYZ data, if it includes datapoints I am not already familiar with, there's often a whole several-day process in which I have to:
hunt down somebody who works on the application to find out what module, page, and field the end-user is looking for
then hunt down one of the guys who can tell me what tables in the transactional DB said page points to
then between myself and my boss, find or figure out how and where the transactional table ends up in the datawarehouse.
So much of this could be resolved by a crosswalk document or two, but no such luck. Every time we make a new discovery I just add it to the knowledgebase of 'codebits.txt'.
Admin
Try adding this layer: have your boss, team mates and stake-holders spread across the globe in different time zones with zero introduction to the business and even less of an intro to the code base, which I would wager floats around 1-2m loc.
Fighting tooth and nail to get help with the build process, extension points, etc., etc. Even questions like "where do I put my code" go unanswered. It's demoralizing at best, but if you stick with it, you will eventually get through it because everyone else on the team went through the same thing.
As advice, I would recommend this: don't ever settle for one word answers. Dig and persist. Be a pest and takes notes. This about it, how the hell else are you supposed to learn?
Admin
That's because you're learning it and not teaching it :)
Documentation and training take up a lot of time, and time is budget. I recall that doing prep for roughly an hour-long class took close to a day. About 6 hours to prep, 1 hour to present, and if people didn't take good notes, they'd just forget what I told them in a few days. So, roughly 1 business day for me, during which time I could've written a chunk of code.
Was it worth it? I thought so. I actually enjoy training. But many people don't. And even MORE people (usually business people or managers) say "Is it really worth our time to do that?"
Yeah, if it were up to me, 10% of our time would be spent on training-- teaching, learning, research, etc. But the higher-ups will often veto that, because on paper, it looks like it takes them 10% longer to complete their projects. Never mind that well-trained people work better and faster-- that's difficult to measure.
Anyway, yeah, that's par for the course. If you want to learn, ask questions gradually. It'll take a long time, but you'll get there. I don't think I'd expect it to be taught nicely and concisely, the way it was done in college.
DaveE
Admin
How you ain't getting return address from emails?
Admin
It is possible, and honestly easy, to send emails anonymously. A fair number of our submissions come from people who use a non-existent email address as their reply-to.
Yes, I know, I replied to Nagesh, but it's worth pointing out.
Admin
Thanking you, kind sir!
Admin
As someone who just went through the same thing, I feel your pain S.N. I'm an intern at a pretty big company, and, having never been in this sort of environment, I felt confused since after I spent a week watching new-hire videos about company spirit, values (heck, even a product presentation video that explained what to write in what part of the whiteboard when presenting to a client), all the intro I got from the dev team I'm working in was "we use maven, here's a repo link". And the aforementioned link pointed at a code base of over 10,000 source files, some of which several thousand lines long with only a javadoc saying @Author David/Jack, etc. at the top. Searching for something would often hang my IDE for several minutes at a time.
So my only advice is this - keep digging. You're new and no one expects you to show up the second day at work asking "What's next?" Focus on the corner of the codebase you need. Once you have an understanding how it works, starting expanding outwards. I like to take lots of notes (mostly on paper - still haven't found note taking software as flexible as paper :p) and slowly wade through the code, stepping through the code in the debugger, jumping back and forth between implementations and interfaces, etc. Eventually it'll start making sense and once you understand why one piece of code was written the way it was, you'll start to see the reasoning behind the rest of the code a lot faster.
Admin
I've struggled with the same issues in the same business for years. In my case, it isn't so much that the problem domains are incomprehensible - what it usually boils down to is a combination of end users who never really understood the length and breadth of the domain themselves with an unhealthy dose of "this is just how it's done, because we've always done it this way", and a sprinkling of "that's just what the customer wants."
For many years my department just coded to the end user specs, and what ended up getting produced was barely usable, with many rewrites, additions and subtractions. Frankencode from hell has been the norm. Part of the problem, which keeps me from (totally) blaming IT management, is the cultural idea that IT is a cost and a necessary evil, not a resource.
But... I happen to be an owner, and I have a little bit - a very little bit - of leeway, and I'm not afraid to push issues when I see them. I'm not an expert code monkey; I consider myself only adequate. But what I do is the bane of Agilistas - the Big Deal Up Front.
A big part of what my company does is agriculture, something about which I know very little. The existing system was a giant WTF, the domain was a great big unknown to me, and I needed to rewrite it. And we pump millions of dollars through it. What I did to make it happen was I took an entire year to work on and off with the primary users, actually helping them do their jobs. At times, I even filled in for them when it was needed. All the while, I did the absolute minimum to get by in the code - often by massaging the data directly - which in reality wasn't very much less than my predecessors. By the end of that year, though, not only did I know enough to rewrite the apps and reports, I was able to solve the problems that flew below the users radar.
The take away is that I think I write much more useful software when I am not just a code monkey, but also a business professional. In some ways, my paradigm is diametrically opposed to the way the Agile folks do things. They've got some good ideas, but IMHO the Agile crowd are... well, that's another discussion. Still, I think the balance that Alex speaks of has a lot to do with how you will/are forced to work.
Admin
I agree with the OP it's not OK but it is what it is. I've just started my third book of notes and I have loads of files explaining even the most basic details of code, procedures and the business in general. It has certainly helped me in my work understanding the bigger picture, and while it's not a requirement of my job it has meant I've been able to ask important questions when change occurs.
As everyone has said, yes it's frustrating but little by little you'll get there, and when you do you'll be able to help those who follow you (you may not get a financial reward but it's good karma).
Admin
This kind of work environment also stresses the importance of good code. Being a small cog in a huge machine, other cogs get to look at your code and modify it when necessary. It may be months/years after you wrote it, but it will someday need to be changed. That will be the day, if you were inattentive or rushed or God forbid incompetent, that code will end up on this site.
Admin
Let me answer this as someone who hired you, or at least someone very much like that. I am in your bosses position, the only difference is that I've had a bit to drink tonight and the anonymity of the internet lets me dispense a little wisdom safely.
You're disposable, 9 out of 10 of my new junior hires are useless. Let's face it, only 2% of people are developers and as far as I can see they're randomly distributed among the population. Every cent I spend on you beyond your salary is a waste of money and that absolutely includes training.
So why did I hire you? Ah, simple, because you might be part of that 2%. Far above you lie my A-team, my star developers. These are the guys "getting stuff done". What I'm hoping is that I might luck in and in this bunch of new junior hires find that 2/100 who will pay off.
Sure I could nurse you all, offer training and "mentorship" but hell, do you have any idea how much that would cost? I might raise the sucess rate to 10/100 (at most) but would waste months of man hours from my A-Team to do it. No, this way is easy, churn and burn, can't figure out a 747, not A-team material, go apply for a PHP role.
Harsh but true, I'm not a social worker, I don't care about you and if I could find out where you sat in the 2% rule then we wouldn't even be having this conversation (welcome to the A-team). Suck it up or move on, there are plenty of rewards for you at the top (did I mention the A-team make well north of 6 figures?) but until then you're going to have to fight for your living and that means learning as you go (for a long time to come too).
Admin
Admin
I think this is a OpWTF. In the first few weeks you're not going to be a master of the entire system understanding how all the flywheels turn the rods, which turn the cogs, which interlink with the exanguination devices, which drip on the vampire hamsters in the wheels, which makes the system work.
What I would expect is to get a high level view of the system and the major components in it. Obviously as the company invests more institutional knowledge into you you'll learn more about each subcomponent. I've been lucky enough (in my professional life) to have supervisors that sit down with me for about 3 hours in the first few days to explain some of how the system works.
When a new guy comes in that I'm required to mentor, I budget about 2 weeks of my time for "trainee support". It pisses my boss off to no end, but after showing them how much time I actually spend during that trainee period and how much my project schedules slipped, they stopped complaining.
Admin
A few advices:
It's tremendously easier to learn complex system in the context of an assignment. You can approach people who weren't approachable before, because you have a reason (assignment) that you need to accomplish. It's also easier to structure new knowledge -- as a tiny vertical, that goes across potentially many components, but all around this particular assignment.
Unsure about what to do because you know too little? Take an assignment ASAP and try it. Every time you start working ask yourself "what is the next step" and if you don't find answer yourself, ask your peers and ask your boss.
Good luck!
Admin
As a newby, you aren't going to understand the business. Until you understand the business, you can't understand how a particular component fits in to the overall picture.
The important thing is that you don't need to understand the business to do your job. That should be taken care of by your project manager/team manager/mentor, who does understand the business and project (or does well enough), and can break it down into bite sized chunks for you to develop.
Whilst you are developing code, you should be absorbing how the system works, and understanding more about your business.
I can understand how someone could get frustrated in this position, but it is unreasonable to expect a long period of time being trained on the project or business - that is NOT YOUR JOB! You're a junior developer - your job is to develop the chunks of the project you've been told to develop, not to be the understudy to the technical architect.
If you were transitioning onto the team as a project manager, or a technical architect, than for damn sure, you should be trained on the project. But then, if you are coming in to those roles, you should almost certainly have the domain knowledge required to understand the specifications, or the skills to pick that up quickly without requiring special training.
If you don't like this environment, look for a job in a smaller shop. "Bob's Country HTML Shack" or similar.
Admin
"Be a pest and take notes." Sound advice.
More than once I have been in an environment where the procedure for doing something basic is long and overcomplicated. The only way to get through this is to get someone who knows how to do it to show you. Take notes, as you watch, make him back up and repeat a step if you don't understand it, then when finished write it all up on the company wiki. Use the notes you have generated to test whether they actually do all work, and if not, amend them. Then write an ant script to do everything you have documented.
This is the only way forward. When doing this, there's always somewhere it goes wrong, and when you ask, it's "Oh yeah, we forgot to tell you that / didn't you know that / why has your machine not been set up so that ..." and on it goes.
Three months later there will be a new addition to the team, and you will be expected to baby him through the process of setting up his environment, and you'll be able to say: "Huh. When I was new I didn't have any notes to work from, I had to write them myself." (sniff)
Admin
Attention, TDWTF. You are officially being put on notice. Look for my email.
Admin
and that is in no way, shape or form related to receiving no basic assistance in getting starting...
or the quality of your decision-making when you make a job offer.. ?
about one-tenth the amount being wasted by the present method ?
you are (mis-)attempting to emulate the ghost of Harold Geneen, and I claim $5 for recognising that...
For anyone not familiar with that scenario: Harold Geneen built ITT into a ( controversial ) international conglomerate in the 1960s and 1970s, inspiring praise and condemnation in roughly equal amounts along the way...
However, his legacy was mainly a generation of American managers who skimmed his book, or read a magazine article about him and somehow managed to misinterpret it into the belief that "the key to successfully running a business" == act macho and repeatedly shout at subordinates that you "don't care" about them...
Said generation went on to apply this belief in the 1980s and 1990s, yet curiously their businesses were often not successful, with entire industries falling to Japanese competitiors...
cf Cargo-Cult Management, AKA "wearing a black jumper and jeans because that other guy used to"...
Admin
I have gone through this at my current and last jobs. The best advice is whatever you learn write it down so that you can pass it on. I have been on my job (system engineering with very little programming) less than a month now and encountered the same thing. I have started a document that links pages on the wiki, share point and information I have received in conversations. I presented this to the director and the principal engineers and received praise for showing initiative. This is something the company doesn’t have and while I am not experienced enough to know if documents are wrong; I have been able to create a single location where one can start learning the system.
Admin
I recall my first days as a developer. Take some solice in recognizing that it's OK to feel overwhelmed. I certainly did. Even with some hands on experience, the task at hand seemed way bigger than I could possibly imagine. I didn't know where to start. After a while, you get more comfortable with all of the unknowns. Don't get me wrong, you will make some mistakes, and sometime not knowing is going to bite you, but you'll eventually figure out when it's ok to not know something. As a for instance, my focus is on data work. While i understand some of what goes into maintaining a high avalailabity environment, and I have come to appreciate this, instead of feeling like I need to know about all that goes into it.
Admin
"Knowing the business" and "being a technical architect" are loosely related at best, in that we usually expect someone at the level of the technical architect to know the business, so that he can take its oddities into account in the architecture-level designs.
However, knowing the business - knowing what the domain terminology means, how people use the software, etc. - is important. No, you don't need to be able to be a wholesale mortgage trader to develop a system (or a small part of such a system) for such traders, but it helps you to make the system better if you do have at least some understanding of what they do and how they do it.
Example, also from the finance industry, but this time in the equity side of things. One particular client had spawned the Project From Hell, a sort of trading report that had mildly exotic and distinctly idiosyncratic requirements, including being fed into someone else's automatic analysis system.
OK, so a couple of other guys had beat their heads on it, and had, in effect, run away screaming. So they gave it to me to look at. By this time I had already gained a better-than-merely-basic understanding of what equity trading involves, but that only helps at the general level. So the client sent in half a dozen of their senior traders (the guys who were doing the trades that I was supposed to be chewing through), and I gave them a presentation.
I stood in front of them in a meeting room and scribbled on a whiteboard, telling them what I could see from the requirements, and what I thought that meant about what they did from day to day. I highlighted cases I thought were weird, and so on.
And then I threw it open to them to tell me what I'd left out, what I'd included that should have been left out, and anything else that differed between what I'd described and what they did.
I got good feedback, and detailed answers to some specific questions. They got to see that I cared about what I was building for them, and that I wanted it to be right for them.
But I could not have done it if I didn't have a better-than-merely-basic understanding of what equity trading is about. (No, I don't know enough about it to be an equity trader, but I can understand what they are talking about, and who those guys on the NYSE trading floor were in Wall Street.)
Domain knowledge will help you to change from a code monkey to a productive builder of software. It is the most valuable knowledge you can ever acquire, although knowing where to find the ingredients for a Gimlet comes close. (That's a 50/50 mix of gin and Rose's Lime Cordial in a chilled cocktail glass, as dictated by God and Chandler. The lime cordial isn't so easy to find in France.)
Admin
Ok: on wikis you can create a link by putting square brackets around the term.
Edit the wiki page if you are able and put square brackets around each term that needs describing.
Note that the link will probably not exist yet, but in time it will be populated.
Admin
All excellent advice.
This may help along those lines.
I've been doing this 30 years, and the first thing I do when I start a new job/project is start a series of Outlook Notes (or some sort of cheat-sheet file(s) if you're not using Outlook), each to be a quick reference for one specific thing. For example: db url/login/passwords you will need. How to extract a project from source control and hook into the build system, how this or that feature logically works, or a high level call stack to use as reference.
When you ask someone how to do something and they give you a 2 second hand-waving explanation, just say: could you please explain that in more detail - and WRITE WHATEVER THEY SAY DOWN, put it in your cheat sheet, and correct as required.
Given the idiots we all encounter on a daily basis, if you have half a brain, you will catch on; it's just slow going at first.
OBTW: if your boss expects you to hit the ground running even though you have little experience, you probably need to go find another boss; don't wait for him to be stupid and fire you - leave on YOUR terms.
Admin
Welcome my son, welcome to the machine. Where have you been? It's alright we know where you've been. You've been in the pipeline, filling in time, Provided with toys and Scouting for Boys. You bought a guitar to punish your ma, And you didn't like school, and you know you're nobody's fool, So welcome to the machine. Welcome my son, welcome to the machine. What did you dream? It's alright we told you what to dream. You dreamed of a big star, he played a mean guitar, He always ate in the steak bar. He loved to drive in his Jaguar. So welcome to the machine.
Admin
When I started at my current job, I was handed a "Getting Started" instruction list that outlined rather nicely how to set up your machine to build the team's current project from source (and how to get the source from the repository). The level of detail was somewhere around "Get boost_vXX.zip from yyy.zzz.tt/boost, extract to local folder and make environment variable BOOST_DIR."
That got me up and productive fast. But it was a document that was made and maintained at the lowest-level by my team's members. Someone had just grown tired of holding the newcomers' by the hand. I got lucky.
If your team does not have such a list, make one! Saves everyone's time. And if no-one in your team remembers the whole procedure, just fill the blanks when the next new person comes aboard (and they have to be figured out anyway).
Admin
...and may the source be with you young padawan
Admin
Remember that part of the job description when you applied that said "Must be a self-starter"? Well, this is where that comes in, and a big part of how they'll judge you.
I actually think it behooves young devs to start in some sort of Tech Support and/or QA role when first joining such a company. This affords them the opportunity to contribute while learning the ins and outs (and foibles) of the system.
Admin
Lissen, kid (and, S.N., as it seems you just started your first job out of college, trust me, I am fully qualified age-and-experience-wise to be your father and thus can call you 'kid' - got that?), you are now in the Real World. This is not school. This is not an internship. This is not some ivory tower where everything is clean and wonderful, all designs are immaculately pure, and there's always time to slope off for a beer if things start getting tough. This is not an environment where someone is going to pick up your shirt and wash your socks and wipe your puckered little derriere for you. You are now in an environment where, despite not knowing said derriere from a hole in the ground (quick lesson - the hole in the ground smells better - stick your nose up your bosses backside if you need to find out), you are expected to Perform. This means that you are going to be handed an ill-defined requirement scribbled on the back of a three-week-old cafeteria menu by the illiterate monkey who just happens to be your project lead, which directs you to make a series of business-critical changes to an unknown number of programs which neither you, I, the project lead, or Jesus Christ hisself has a complete understanding of. No matter - it's your job now, sweet cheeks, and good luck with THAT! 'Training'? Gee, I remember that - it stops right after you get handed the pretty paper and take off the funny flat-topped hat. You need to learn something? There's a whole effing internet out there, my lad, and Google is only a mouse-click away. 'Mentoring'? Say what? Oh, you mean 'brainwashing-and-indoctrination'! Sure, yeah, you can probably get a senior suit to pontificate at you - and good luck with THAT! You want everyone to speak in terms that you can understand? Not gonna happen. All businesses, organizations, groups, etc, have their own little language. It's called "jargon" - a specialized language that experienced practicioners use so they don't have to use so many words that they forget WTF they were trying to say in the first effing place! And you're right - you don't know it. You learn by A) being clueless, B) asking questions, and C) figuring it out from context. This is a little thing we call "learning". It's not really hard - babies do it all the time. In twenty-two years they go from not being able to do anything but eat, pee, poop, and scream to being self-centered little barstuds who believe the world should be fed to them on an effing platter. Your inability to function in an unstrutured environment is not of interest or concern. Root, hog, or die! As far as programs go - there's exactly ONE way to learn what that they do - dig in and READ THE CODE! Documentation is bullshit. User's don't have a clue. Co-workers lack time and inclination. And, ultimately, nobody can stuff knowledge into your head. So how're ya gonna learn it? READ THE CODE! READ THE CODE! (What're ya gonna do?) READ THE CODE! Oh, and if the above seems a bit harsh - yep, reality's like that. If'n you can't hack it perhaps you'll work hard to shine up them apples, and polish up that brass, and decide that, really, that stuff you smell when your nose is up some illiterate monkeys backside is actually roses, and maybe you'll just get yourself promoted to illiterate monkey! I hear there's quite the supply of three-week-old cafeteria menus just waiting for hard chargers such as yourself. </rant>
(Golly, I seem to be feeling a mite testy today. Heh. Probably just a reaction to the illiterate monkey's code I was reading...)
CAPTCHA: similis - like a veneral disease, but not quite...
Admin
I'd add that every job I've started, I felt lost at first, and worried everyone around me would notice what a clueless boob I was.
I've since learned this is entirely normal.
You'll also find you really don't need to understand everything to be useful. I work as a sysadmin in a graduate department at a university. I'm surrounded by people MUCH smarter than me, doing research I can't even understand the abstracts of. But that's okay; after at most a few rounds of questions, I can usually get a handle on what they need from me in terms I can understand. My job is to deal with all the fiddly little details of installing software and running the systems, so they can focus on the big picture. Understanding the big picture, as interesting as it might be, would actually be a distraction from my work.
To borrow the airplane analogy, the guys driving rivets or assembling engines at Boeing don't learn how to fly a 747 as part of their training. It'd be a waste of everyone's time, because what they really need to understand is the little piece they're working on.
Admin
There is a story of a woman who worked in a factory assembly line for several decades, after a while she broke a record for never taking a sick day and being the longest standing employee. At lunchtime they held a celebration for her and in the course of which management asked her what she thought of the company product, she said "I don't own one and I don't need a new vacuum cleaner.". Guess what, they didn't make vacuum cleaners, not even close, but that didn't matter, she did her job effectively and worked hard.
That said I am not sure I could work like that!
Admin
So...so you think you can tell heaven from hell? Blue skies from pain? Can you tell a green field From a cold steel rail? A smile from a veil? Do you think you can tell..? Or did they get you to trade your heroes for ghosts? Hot ashes for trees? Hot air for a cool breeze? Cold comfort for change? Did you exchange a walk-on part in the war For a lead role in a cage?
How I wish...how I wish you were here We're just two lost souls swimmin' in a fish-bowl Year after year Runnin' over the same old ground What have we found? Same old fears I wish you were here.
...
Nobody knows where you are, how near or how far Shine on, you crazy diamond Pile on many more layers, and I'll be joining you there Shine on, you crazy diamond! And we'll bask in the shallows of yesterdays triumphs Sail on the steel breeze Come on, you boy-child, you winner and loser Come on, you miner for truth and delusion, and shine!
CAPTCHA: feugiat - (Sticking with the Floyd motif): Feugiat, we gotta get on with these Gotta compete with the wily Japanese There's too many home fires burning and not enough trees So feugiat, we gotta get on with these
Admin
Part of the answer is that this is the difference between big systems and small systems.
On a small system, it's perfectly reasonable for every team member to understand what the entire project is about. Not to have every field on every screen and every line of code memorized, of course. But competent team members should know that we have some screen where customers enter orders and they have to select the items they want and enter their shipping and billing information, and we have a database with a table for all the products we sell and another table for all the orders, etc etc.
At some point a system gets big enough that this is impossible. If you are working on the vacation and sick time modules, you may be dimly aware that there is a company-paid disability insurance module, but beyond its existence you know nothing about it. There may be whole subsystems that you don't even know exist.
Personally, I hate working on such big systems. Part of it is purely emotional: I don't like being a tiny cog in a big machine, where I don't even know where we're going or why. But on a practical level, such big systems have problems that small systems don't. The things you are working on have subtle interactions with components that you know nothing about.
Every change you make has the possibility of breaking parts of the system that you didn't even know existed. I've run into this many times: I modify inventory management, and inadvertantly create a bug in shipping manifests. I modify customer name and address entry and break promotion discount calculations. Etc.
Different groups may find themselves working at cross purposes. The order processing group is designing a new search function based on inventory category while the shipping group is working to eliminate inventory category from the database. As no one knows the big picture, no one knows how all the pieces really fit together.
There are ways of dealing with such issues, of course, but no one has yet found a true SOLUTION that makes the problems go away.
I once saw a study that compared the size of a system to the success rate. It was no surprise to me that the success rate for very large systems was extremely low. I used to work for the Air Force, and it seemed like every couple of years somebody got the bright idea that we should have one giant system that tied together everything that the Air Force did. Instead of having one system to manage inventory and another to order parts and another to handle payroll and another to plot flight paths, etc etc, why not have one system that tied it all together? So like the general could type in that he wanted to send a squadron to bomb this particular target, and the system could automatically requisition the bombs from inventory and calculate fuel requirements and give the pilots their combat hazard bonus and notify the mechanics when the planes were expected to return so they could plan maintenance etc etc. Sounds like a great idea. And every time it was tried, they would spend millions or tens of millions of dollars on it, and never deliver anything. I saw probably half a dozen of these projects fail, one after the other. Because human beings are simply not capable of managing something on that scale, at least given the current state of the art.
Admin
Something I've always found fascinating about the IT business is that everyone expects the computer guy to come in and in a few months -- or a few hours -- know more about how the business works than the people who have been doing it for decades. I once got a job with a company that made software for doctors' offices. And bam!, I was immediately expected to know all about "International Classification of Diagnosis" codes, how doctors' offices interact with insurance companies, how medical records are kept and organized, etc etc.
In some ways the IT guy has to know the business better than the business people. The business people often deal only with the routine cases, but the IT folks have to consider every possibility. I don't know how many times I've had conversations where I bring up some abnormal case, like, Me: "What should the computer do if there is only enough stock to partially fill the order? Do we send the customer what we have and back order the rest, or do we send nothing until the whole order can be filled, or what?" Business person: "Oh, don't worry about that case, that hardly ever happens." Me: "But it must happen sometimes, right?" Business: "Well yes, sometimes, but not often." Me: "So what should we do when it happens?" Business: "Oh, don't worry about it, it's very rare." Me: "But the computer has to do something in that case. I can't tell the computer to just not worry about it." Business: "Will you stop wasting time on these rare cases! I told you it hardly ever happens! Just do something reasonable!" Me: "Okay, so what's 'reasonable'? Should we make a partial shipment?" Business: "Not necessarily. It depends." Me: "Okay. Depends on what? Under what conditions do we make a partial shipment?" Business: "I don't know, it just depends. Stop bothering me with these details! Just do something reasonable!" Etc. I've literally had users get yelling mad at me for asking them about details and special cases.
But the IT guy has to consider every possibility and every detail. While the operating folks can make things up as they go along, use their judgement, etc, the computer can't. We have to distill everything down to hard and fast rules. Which means we have to know all the details.
Admin
What a great opportunity!
Read the source. Find the program entry point, and the modules that execute at startup. Find the secondary storage, file and database routines. Find the user input areas.
Take a each module/class and try to understand what it does.
Once you know how to navigate the source, you will understand the how, if not the why.
And the real secret -- grab your nearest company old-timer and take him out for beers.
Admin
Look, if you want to write some spiel about what you think the young folk should do in their first jobs then write it. I don't see the point, myself, but whatever. But don't write a fake letter that subtly acknowledges how great you are with the lie that "this particular email had no return address", OK? Who do you expect to believe that? Who are you, Cary Tennis? Fakery and bullshit and lies are never appealing. Just speak your mind if that's what you want to do.
Admin
The advice to just "suck it up" is precisely what's wrong with the business software non-engineering. I'm not arguing that anyone can get the entirety of a large system in their head, that's not usually possible. But I do argue that a certain process must be followed that not only yields higher quality software, but also improves the situational awareness of team members.
Some advice from IEC 61508 and UL 1998 as to the management of the software engineering process wouldn't hurt. I can't understand people who, in a large business setting, argue for and code without having traceability from requirements at least to code, if not to tests and validation. That process is exactly what's called for when you have a big team, as everyone can refer to the managed documentation and understand the cog that they work on, or even have understanding of the structure of the whole system, should they need to.
It's not about training, it's about having a process that adds value to the company. Suppose the big bank irks their IT team and everyone walks off the job and resigns, upset so much that no money on the planet will get them to consult for the bank. The replacements will spend months just figuring out where the latest version of the code is, much less what the heck does it do. You'd think that the notion of replaceable cogs in the machine would appeal to the beancounters, but apparently they pay lip service to it only.
Admin
Admin
Admin
IOW, it's a solved problem, there are even competing software tools to aid you in this process! Heck, there are even tools that aid in risk estimation, and help you decide to what level of testing and validation a particular software module should be tested. It's not popular outside of safety-critical system circles, but if there were no solution then we'd have modern fly-by-wire planes falling out from the sky left right and center, and various process industry plants would be blowing up every other week. Get real -- just because you have no clue about something, doesn't mean it isn't a solved problem.
Admin
My employer has a centralized database for tracking health and safety information for dangerous chemicals. Now, the data doesn't start centralized- it needs to be gathered and scraped from a thousand legacy applications that were used by a variety of business units. And then, once it's managed in the central system, changes have to migrate back out to those legacy systems, where people actually do their work.
Now, the underlying design of this is full of WTFs driven by doing integration in the data-layer, and it could certainly have been done better. But due to enterprise constraints, the actual implementation ends up being held together by hundreds of SSIS packages, scheduled console applications, mainframe FTP operations.
When it comes time to answer, "How does Europe know if this chemical causes cancer?" the actual implementation of the process is spread across so many different systems that no one person can answer the question.
The amazing part is that the process works. It's business critical, it's arcane and complex, but it works fairly consistently. You don't realize that it's terrible until something goes wrong, and then you learn that there's really no way to understand what went wrong.
Admin
Admin
Alex, this is the best article you've ever posted on TheDailyWTF. I could see this becoming a regular feature.
Also, it's funny you mention Fannie Mae; that was my first job out of college. I have an Econ degree and CS minor, and I was still completely blown away by the depth and complexity of their business. Fortunately, Fannie Mae offers (or used to?) an FNMA101 class to all employees and contractors that does a great job of explaining how the business works a high level. But in my experience, only really large organizations have the ability to pull of sophisticated training like that.
Even with extensive training, the detailed business logic is still impossible to master because the business logic is driven by the real-world necessity of business people cutting idiosyncratic deals in any way possible to get new business. We had business rules at FNMA like, "if the security code begins with "M" and it was originated in Arkansas or Arizona between 1996 and 1998 with a mortgage amortization code of 17, then put it into file A, otherwise put it into file B". The reason behind that business logic is some guy (who probably didn't even work there by the time I started in 2006) put together a 3 year deal with banks in Arizona and Arkansas to process loans in a particular way for them.
Admin
I think you mean, "only 2% of people WHO CLAIM TO BE DEVELOPERS are developers," right?
If 2% of the population were developers, then it would be much easier to hire the right talent. I've struggled for years at small companies to hire qualified developers. Half of the guys that come in can't even write FizzBuzz on the first try. (Admittedly, in many of my cases, the small companies just couldn't/wouldn't pay enough to hire the right people.)
In either case, if you're hiring entry-level employees and then consider their training to be a wasteful overhead, then you're an asshole. Entry-level software developers will undoubtedly require more training and hand-holding to get started than an experienced developer. There are a lot of tools and skills you just don't typically learn in school, and there are also a lot of life lessons about how to interact with coworkers that aren't taught in schools either.
If you don't have time to train an entry-level employee, then don't hire them. You're not doing them or you any favors by setting them up for failure.
I'm not suggesting you should run a welfare agency. By all means, hire effective people and fire ineffective people. But don't treat people like shit. Even if I was on your A team, I wouldn't want to work for somebody like you.
Admin