Most of the emails that arrive in The Daily WTF inbox are some kind of a submission. Or a hate mail. But every now and then, some one will request something a bit out of the ordinary: advice.

Hi Alex,

I recently started my first "grown-up" job as a software developer. 
As exciting as it is to get paid for doing what I love, I can't help but wonder 
if I'm expecting waaaay too from a company.

My main issue is that I know virtually nothing about the (very large) application 
I'm maintaining, or even the business domain. There is a business requirements wiki 
(and a whole team who can apparently answer questions about it), but it's filled 
with words and terms that are so domain-specific that it's basically impossible 
to get a proper understanding of things. It feels like I'm learning to fly using 
only blueprints to a Boeing 747.

I was really expecting that someone would sit down with me and give me a nice demo 
of the ins and outs of the application and the business, but no one seems to be 
willing or able to do that. Messing around with a test version of the application 
doesn't help either since there's no product documentation accessible and the little 
help that's available is littered with domain intensive keywords.

I feel that "it's complicated" and "this is a fast-paced environment" 
is no excuse to skip proper training and to not give due importance to knowledge 
transfer to new hires. I feel that if I were running the department, I'd accept 
the overhead and just make sure developers could understand the applications and 
business they're maintaining. Is this so much to ask?

How exactly am I supposed to understand the application if no one else seems to know 
(or be willing to share) what it does?


I do my best to respond to inquiries like this, but this particular email had no return address. So that got me thinking… why not publically answer inquiries like this?

First and foremost, I'd like to welcome you to the machine, S.N. You are now officially a small cog in a small part in the impossibly complex machine that makes the world turn. As software developers, it's our job to model this very same machine, or at least our very small part in it, so that it can turn that much more efficiently.

My first appreciation for all of this came with a job at a bank. By then, I had already done the mortgage thing and I felt pretty confident that I'd be able to understand how the bank's wholesale mortgage management system. Waitasec. Wholesale mortgages? I thought banks worked by lending depositor's money at a higher interests rate than they paid out? Waitasec. Banks fund loans originated by brokers? And they sell these loans on an exchange? Uhh, I thought Fannie Mae made chocolates or something?

Up until this point, I could understand the applications I built and maintained. I prided myself on not only being able to write great code, but on understanding why the code needed to be written and the costs/benefits of that code. One time, I even saved the business thousands of dollars (and many lines of code) by insisting that we cancel building the search feature and instead train the handful of users to CTRL-F. I would have never come to that conclusion without taking the time to understand why the requirement existed.

But the bank… was different. No one could give an overview of the wholesale mortgage management system. Developers and business analysts kinda had an idea how some of the pieces worked, but no one seemed to truly understand how things fit together. And everyone was okay with that. They just did their job and focused on their corner of the world, whether that was an elegant architecture or a masterpiece requirements document. I found myself at a crossroads, in fact the very same one that you, S.N., are at today. Now it's time to choose a path.

  1. Write Code. This is, after all, what you're paid to do. Input requirements and output code. It's not as boring as it sounds, and there are some absolutely amazing things you can in code. But there's no way of knowing – nor is it your job to know – if the code you write solves a real problem. You can only assume that the requirements are correct and that the code will be used correctly.
  2. Build Software. There's a lot more that goes into software than just code. It starts with a value proposition that will save or create revenue and it ends with an implementation that's as fluid as the business requirements that defined it. This path means you not only must write code, but go out of your way to deeply understand the requirements and how your code will be used.

I took the path less traveled and tried to learn both, but I quickly found out that the more I learned, the less the I understood.

Every corner I turned – whether it was on the loan origination side or on the loan packaging side – lead to an entire field of knowledge that I couldn't truly understand without years of experience. To write code that helps the "numbers guys" hedge risky mortgage risk, you don't really need to know what the broker registration system does. And thus, there was a good reason for no training or extensive documentation: it would fill an entire Library of Congress or two, or it would be uselessly terse and offer no real understanding.

The only way that the wholesale mortgage management system – software, process, people, and all – could work is if everyone masterfully played their own part. The business analysts needed to understand the requirements so that I could code to their specification within the larger system that the architects designed, all at the direction of project managers who are implementing the executive team's directives. It's exciting to be part of such a large system and solve all the complex development challenges surrounding it. But it still meant that I'd be "only" writing code, and the only way to build software was to do something else. So I did.

I started Inedo and went on to build software (BuildMaster and ProGet). But just as software is more than just code, a start-up is more than just software. I had to learn and do a whole lot more than I bargained for – accounting, marketing, legal – and as a result, I hardly write any code any more.  It's exciting in a different way, but there are days I long for just writing code.

So to sum up my advice to you, S.N., it's all about finding balance.

If you want to work on the big, Boeing 747-sized projects, you'll have to accept that you'll never be able to fully understand everything you'll be working on. 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. But be careful, the closer you get to fully understanding the operation of the business… and you may just become it.

Have a pressing question that you need answered? Need advice? Send us an email: [email protected] The WTF "doctor" is always in.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!