Working with Developers

Get Started. It's Free
or sign up with your email address
Rocket clouds
Working with Developers by Mind Map: Working with Developers

1. Why we love it

1.1. We solve problems

1.1.1. We like to think we make life easier

1.1.1.1. 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

1.1.2. Our solutions are concrete, observable things

1.2. We perform magic

1.2.1. 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.

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

1.2.3. Either way, it's strikingly addictive

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

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

2. What are our inner conflicts

2.1. Software is an asset, source code is a liability

2.1.1. What is software

2.1.1.1. Content Management System

2.1.1.2. Neat calendar application

2.1.1.3. Cool video player

2.1.2. We write source code to make software

2.1.3. How is what we write a liability

2.1.3.1. Additional lines of code mean potential

2.1.3.1.1. Bugs

2.1.3.1.2. Security problems

2.1.3.1.3. Lines we need to understand in 14 months

2.1.3.1.4. breakage from code rot

2.1.3.1.5. places for a misunderstanding

2.1.4. What does this drive?

2.1.4.1. New code is the biggest liability of all

2.1.4.1.1. Old, tested code has been battle-proven and is less likely to be full of bugs and broken

2.1.4.2. We want the simplest design that will meet your needs

2.1.4.2.1. We love consistency

2.1.4.2.2. We want to write as little new code as possible to meet your needs

2.2. Change is inevitable, and expensive

2.2.1. Changing software tends to be complicated

2.2.1.1. Examples

2.2.1.1.1. Add, display, and sort on on a new field to DCGS

2.2.1.1.2. Migrate HPBA

2.2.2. Changing data can be a nightmare

2.2.3. The wrong design can make change very difficult

2.3. There is a vicious tradeoff between simplicity and over-engineering

2.3.1. What we want is the simplest design that meets your needs

2.3.1.1. We call this design "elegant" and feel wonderfully happy when we hit that

2.3.2. 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

2.3.2.1. That's expensive

2.3.3. 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

2.3.3.1. This can be just as expensive as scrapping a simple design in the long run

2.3.3.2. More complicated systems are also typically more complicated to use

2.3.3.2.1. There's a reason apple won't add lots of features to its products

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

2.4.1. Every small decision must be made; the computer can't make any decisions for us

2.4.1.1. How should every type of content look

2.4.1.2. What details about your event should the computer display

2.4.1.3. What order should listings be sorted in

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

2.5. Developing software requires a tremendous amount of focus

2.5.1. The number of things you have to remember to write a web application is absurd

2.5.1.1. DCGS requires thinking in 5.5 different languages

2.5.1.2. The more technologies you need to know, the less good you are at any given one of them

2.5.1.2.1. At some point, we had applications in five very different programming languages that we were maintaining

2.5.2. 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

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

2.6.1. If a project's scope increases too much beyond what we expect, it can become impossible to add labor to improve the situation

2.6.1.1. 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

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

2.7.1. During the development cycle, we tend to work more slowly and carefully, while at the same time taking bigger risks with the code

2.7.1.1. These bigger risks mean that we can make bigger changes that are actually maintainable

2.7.2. 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

2.7.2.1. Being in "constant deployment" mode is a poison

2.7.2.2. 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

3. What can you get out of this?

3.1. A glimpse into another, weird world

3.2. An understanding of what we do so you can

3.2.1. Get better products for your clients

3.2.2. Understand what's going on for a less stressful project

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

3.3. An understanding of our strengths and weaknesses

3.3.1. So that you have better teams for your clients

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

4. What can you do to help

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

4.1.1. Be detail oriented

4.2. Find us examples of what it is you want

4.3. Help us get budget for prototypes and for planning

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

4.5. Embrace technology

4.5.1. 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

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

4.7. 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

4.8. Be realistic with your deadlines, constant deployment leads to panic

5. Where do we fall down?

5.1. We hate giving estimates

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

5.1.2. As such, we avoid estimates like the plague

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

5.2.1. 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

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

5.3. We have trouble keeping the really big picture in mind

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

5.3.2. 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

5.4. We have trouble testing our own work

5.4.1. 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

5.5. We have some trouble being really excited about adventurous features

5.5.1. 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

5.5.1.1. As such, we are more likely to push for radical simplification than radical functionality

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

5.6. The last 10% of any feature is hideously boring

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

5.6.2. 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

5.6.3. 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

5.7. We over-rely on technological solutions

5.7.1. We make computers do work for people

5.7.2. 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

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