Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Working with Developers by Mind Map: Working with Developers
0.0 stars - reviews range from 0 to 5

Working with Developers

Why we love it

We solve problems

We like to think we make life easier, When someone realizes there's a problem, using our imagination and creativity, we can often make a machine that solves it, and creates several new problems in the process

Our solutions are concrete, observable things

We perform magic

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

No, it's not actually magic; it's somewhere between art and engineering

Either way, it's strikingly addictive

People use the product of our labor, from which we are not disconnected

It is sad for us when we write something that goes unused

What are our inner conflicts

Or, what makes us weird

Software is an asset, source code is a liability

What is software, Content Management System, Neat calendar application, Cool video player

We write source code to make software

How is what we write a liability, Additional lines of code mean potential, Bugs, We translate fuzzy ideas into very concrete logic. Sometimes, that logic is imperfect, especially when it is very complicated, Security problems, These are like bugs, only they make people cry., Lines we need to understand in 14 months, We spend a lot of our time thinking about how to deal with code so it ages gracefully, We are in this for the long hull, Especially in client service, where budgets change, we know new requests are going to come up, breakage from code rot, Every upgrade, something you wrote could break, Sometimes, you have to upgrade, Features, Security fixes, places for a misunderstanding, Code requires decisions, and often times we end up making those decisions. If we're wrong, the code has to be rewritten, which is depressing.

What does this drive?, New code is the biggest liability of all, Old, tested code has been battle-proven and is less likely to be full of bugs and broken, This drives us often to look for products or other people's code to solve your problems, It also can mean we spend a lot of time learning what someone else wrote instead of writing something ourselves, We want the simplest design that will meet your needs, We love consistency, The more consistent you can be, the easier it is for the computer to handle your problem, Exceptions and one-offs are expensive, They are the most expensive when someone is trying to understand code a few months or years later or when we're trying to make a major change, We want to write as little new code as possible to meet your needs, We want to minimize lines of code per feature, We want features to be as clear and few as necessary, Extra, unused features means extra code sitting around, waiting to break something

Change is inevitable, and expensive

Changing software tends to be complicated, Examples, Add, display, and sort on on a new field to DCGS, Migrate HPBA

Changing data can be a nightmare

The wrong design can make change very difficult

There is a vicious tradeoff between simplicity and over-engineering

What we want is the simplest design that meets your needs, We call this design "elegant" and feel wonderfully happy when we hit that

If we make too simple a design, and your needs end up being much more complicated that we anticipated, we may have to scrap the whole thing and start over, That's expensive

If the design is substantially more complicated than required to meet your needs, every change ends up taking several times longer than necessary; more complicated designs usually require more complicated code, This can be just as expensive as scrapping a simple design in the long run, More complicated systems are also typically more complicated to use, There's a reason apple won't add lots of features to its products

The computer is the source of our power, and it is really, really literal

Every small decision must be made; the computer can't make any decisions for us, How should every type of content look, What details about your event should the computer display, What order should listings be sorted in

When we tell the computer to do something stupid, it does it, exactly as we told it to

Developing software requires a tremendous amount of focus

The number of things you have to remember to write a web application is absurd, DCGS requires thinking in 5.5 different languages, The more technologies you need to know, the less good you are at any given one of them, At some point, we had applications in five very different programming languages that we were maintaining

Writing complicated code requires a specific state of mind akin to writing a flowing narrative; you need focus that excludes most everything else, and if someone breaks that focus, it can take hours to get it back

Brooks's Law: Adding people to a late project makes it later

If a project's scope increases too much beyond what we expect, it can become impossible to add labor to improve the situation, The logic here is that once you have a substantial amount of code, it can take longer to onboard someone as it would to implement that person's features

There's a significant difference between the development cycle and the time before deployment

During the development cycle, we tend to work more slowly and carefully, while at the same time taking bigger risks with the code, These bigger risks mean that we can make bigger changes that are actually maintainable

When we're in deployment mode, we are looking to break as little as possible and work as quickly as possible, so we cut corners and add hacks, which we hope to resolve during the next development cycle, Being in "constant deployment" mode is a poison, The trouble comes when we're in "just about to deploy" mode for several weeks because the schedule was unrealistically agressive and the content or approvals didn't land

What can you get out of this?

A glimpse into another, weird world

An understanding of what we do so you can

Get better products for your clients

Understand what's going on for a less stressful project

Feel morally righteous that you didn't cause us to work through the night

An understanding of our strengths and weaknesses

So that you have better teams for your clients

So you know what to guard against and where to bring us in

What can you do to help

Think about what you need upfront, and think about it hard

Be detail oriented

Find us examples of what it is you want

Help us get budget for prototypes and for planning

When you want to ask for a new feature, think hard about whether anyone would actually ever use it

Embrace technology

I'm not kidding; the more conversant you are with technology, the more likely you will be able to think about your problems in a concrete way that we can actually solve

Remember that the most flexible system is not necessarily the best system

Remember that computers are really, really different from people, and when we've spent a lot of time dealing with computers, it can take us a little bit to get used to people again

Be realistic with your deadlines, constant deployment leads to panic

Where do we fall down?

We hate giving estimates

It turns out, it's absurdly hard to estimate anything in programming that you've not done before

As such, we avoid estimates like the plague

It's easy to get the "new/shinny's"

That is not something we have a lot of trouble with, but we may have the opposite problem; avoidance of new technologies for fears of unknown problems

This is how a company ends up with 8 products written in six entirely different languages

We have trouble keeping the really big picture in mind

Developing is a lot of very detailed work; unfortunately, that doesn't leave a ton of room for keeping the big details in mind

Without the big picture in mind, it's pretty easy to end up spending a lot of time on features that don't actually accomplish what your client needs

We have trouble testing our own work

After you've spent a 70 hours on one feature, it can be hard to test it properly, because you know how it SHOULD work, and therefore you're not likely to think of novel ways to break it

We have some trouble being really excited about adventurous features

We typically have pretty busy workloads and short deadlines, so what to you sounds like a really neat idea to us often sounds like something that's going to throw the schedule off; however, were we to switch places, we promise we'd be all over far reaching feature requests, As such, we are more likely to push for radical simplification than radical functionality

When left to our own devices, we will specify a feature to be as simple for us to complete as possible

The last 10% of any feature is hideously boring

We really like taking big steps and creating something out of nothing

We don't so much usually care about polishing that something to make it usable for outsiders; our favorite work is often "proof-of-concept" work

It turns out that the last 10% of a feature is usually figuring out all the little ways that the other 90% break or are hard to understand, and so is really tedious, time consuming, really important

We over-rely on technological solutions

We make computers do work for people

We assume people should do as little work as possible, even if it's a lot of work to get the computer to do some piece of person work

We will often assume that we need to automate some process that no one expect or even wants to be automated