On respect

Firstly, an apology to my regular readers on the delay to this post.  I’ve had a very busy couple of weeks personally, squeezing out the time I have available to blog. Hopefully things will be back to normal next week.

As a coda to my 3 Dear… Blog posts, I wanted to discuss respect.

• Dear developer,
• Dear customers, and users,
• Dear manager

All of these talk about respect, but I realise that respect isn’t always understood. Respect doesn’t mean to tolerate, it doesn’t mean to accept someone’s position blindly, it doesn’t mean opinion is as valid as fact.

It means that I will try to tailor my message to talk about things meaningful to you, I will be technical with developers, I will talk deadlines and finances with managers, and I will talk to users about their business, not our architecture.

I will disagree with you, but I will be open to the possibility that I am wrong, if you can show me why.

If we can’t agree on something, we must respect each other and the team enough to come to a way forward that recognises without necessarily resolving that disagreement.

I will not respect your opinion. But I will respect your right to hold it. I will respect a hypothesis based on that opinion that can be tested and reasoned about. And I will respect the result of that test, if the methodology is sound. I expect that your first hypothesis will not be your last.

I will not respect you because of the title you hold, your seniority or your ability to bulldoze dissent. I will respect you if your actions demonstrate respect, if your words respect your actions, and your attitude respects your words. Power is not worthy of respect. You will be judged by how you wield that power. I will try and wield my power responsibly.

I am open to change, but not for the sake of change.

Respect yourself and the respect for others will follow.

Advertisement

Dear manager

Good equipment is not a luxury. Bad equipment costs you money.

Training is not a luxury. You don’t want untrained developers. Either you train us and show us we have a future or don’t train us and we leave to get trained, or worse, we stay.

Management is not always a promotion. Let good developers code, and give them a career path that gives them that option.

Not everything we do is visible. Refactoring is important but hidden. Foundations matter, and so does maintenance. If you ban maintenance, you’ll see costs creeping in as everything takes longer.

We need space, and quiet. Read Peopleware: Productive Projects and Teams
and read the research on open plan offices.

Be wary of cutting costs unless you understand the benefits. Sure it’s cheaper to rent office space outside the city centre, but the talented people you rely on might prefer to commute by train. Sure that new laptop costs an extra £1000, but it’ll save developers £750 a year because it’s faster.

We want this released as much as you do. Artificial deadlines don’t help and put pressure on to avoid essential maintenance.

We expect you to have our back. We’ll feed you the unvarnished truth, including justification, so long as you don’t use it against us.

Respect the team. If you treat us as interchangeable resources, we’ll treat you as unnecessary overhead. If you treat us with respect, you’ll have a much quieter life.

Dear customers, and users,

We’re sorry.

Software development is hard. You don’t see everything behind the scenes, so let me give you a few guidelines that I hope we can agree on.

Estimates are called that for a reason. We do our best to figure out how long things will take, we will break tasks into something small enough that we can have some confidence in the number, but we’ve not built this feature in this software before. The only way to know how long something will take is to do it. And then compare the new features we’re working on to that. Given that estimates take effort, and need a lot of detail, estimating an entire system based on an elevator pitch will be about as accurate as guessing the weight of all the grey animals you can see on the horizon. At the moment, I can give you a lower bound if they’re mice, and there’s none hidden, and an upper bound if they’re elephants. If you want more accurate estimates, be prepared to give us more time and detail.

Users don’t understand requirements. You may understand what you do now, and you might have an idea about what you’d like to do, and you will understand whether completed software fits what you need, but written descriptions, visual walkthroughs, and any other design artefacts can only go so far in helping you understand how the software will actually work when you get it. You have ideas about what you want, some more concrete than others, and only some of them actually make sense to build. We’ll help you through the process, but if you can’t answer a question about how something works, it might be because what you’re asking for isn’t clear.

Developers don’t understand requirements either. We need to understand why you’re doing something before we can understand what you want. Your high level requirements that tell us to delete everything on Tuesdays when it’s raining, or that Pogmotians must be able to Fidoodle the Strittles don’t tell us why that’s important, so we will ask questions that you may have to think about hard. We want to build the software that helps you achieve your goals, so help us to understand those, not just the process of what you do.

Sometimes what looks easy is actually hard. But sometimes what looks hard is actually easy. I know it looks like “just” a change to add Google-style “did you mean” to our searches. But Google spent a lot of time and resources to figure out what you mean, and then a lot of effort to make it look easy. Making things look easy can be one of the hardest problems we have to solve.

You are the experts in what you do. If you want software that understands what you do, you need developers you understand what you do. We will work hard to build a relationship, so that we understand your business, because that’s how we write the right software for you. But like any relationship, it will take time. And sometimes we’ll fight, and sometimes we’ll be in sync.

We understand that sometimes you don’t understand. If you can be patient with us with the above, we can be patient with you when you want more detail on what we’re doing and why.

Respect us, we’ll respect you.

Dear Developer,

A happy team is a productive team, the best team since…

You want to work on my team, or me to work on yours? This is what you should know.

Don’t follow me blindly. It’s ok to disagree with me. In fact, I won’t trust you if you just accept everything without question. But you must disagree with respect. Bring numbers, bring frustrations, but leave religious warfare and personal attacks out of it. If that’s what you need to carry your argument, your argument is lost.

Accept decisions gracefully. Once a decision is made, let it settle before bringing it up again. I know you prefer K&R style, but the rest of the team don’t. Deal with it.

Know your craft. Practice it, argue it, read, watch, improve. If you’re waiting 10 minutes for a green build, read a blog post. Embrace knowledge, it is your best weapon in software development.

Make time work for you. Some days you’ll eat the bear, others the bear will eat you. Bank the good days, bite off more than expected and use them to get ahead. You’ll thank yourself for it on the bad days.

Support the team. I know it’s rubbish that you’re the only one who knows the reporting solution. If I have the power, I’ll help you share that knowledge, but you have to give it gracefully. Support others to learn and you will no longer be alone.

Remember life in your work life balance. Office hours are there for a reason. Respect them. There will be occasional evenings and weekends, but they should be compensated by time off or similar. Use that time not to think about work so you can think about the problems fresh. Use the time to connect with friends and family and remind yourself that this job is about people as much as it is computers. Don’t burn out.

Be the change you want to see in the team.

Above all, respect yourself, respect the team, and respect the customer. If you do that, you can be proud of what you produce.

Botnet of things

The Internet of Things is the new hotness. It’s the source of Big Data, it’s the future of clothing and wearables and retail and your kitchen. It’s going to be everywhere. Says the hype. Smart watches. Smart fridges. Smart cars. Smart cities.

Part of my is excited, there’s a lot of possibilities, especially once you start hooking them together either with code, or via services such as if-this-then-that.

Introducing the Maker Channel — connect Recipes to any device or service with a web request http://t.co/e2E45G5MVa pic.twitter.com/atC2mlO6Jc

— IFTTT (@IFTTT) June 17, 2015

Stop for a minute though. Consider that we are talking about a heterogeneous collection of internet-connected devices in your house, on your body, on your commute, gathering a lot of data on you and controlling things around you so you don’t have to.

Do what happens when they’re not controlled on your behalf?

These devices have access to:

• Your WiFi password
• Your connected services
• Whatever their sensors pick up (audio, visual, etc)
• Other devices

Some of them happily connect on unsecured channels.

They are updated according to manufacturer policy (see Android fragmentation and the WebView vulnerability to see how well that works out).

If you accept the 3 rules of network security, and choose not to trust the manufacturer, the cloud services and the network, and want to protect yourself, how do you isolate your threat but still allow the benefits of these devices? How do you isolate the rest of your devices or services if one gets compromised? How do you protect your future data if the services get compromised? How do you protect yourself if your network gets compromised?

Possible solutions:

• IoT DMZ for WiFi – allow devices to access your WiFI via an authentication key rather than password (similar to one-time passwords for 2FA enabled sites), which only allows them to access an authorised list of sites, and not other nearby devices, managed by your phone/companion app?
• Direct network connection (Ethernet over power) rather than WiFi
• Non-personal connection (built-in 4G)
• local data hub that relays the collected information across your local network to a service you choose
• Bluetooth, or other close-range set up (or see ChromeCast, which broadcasts an SSID for phone to pick up, then switches to the WiFi you set up)
• Quick list/disabling of connected services?
• Token auth rather than password auth
• Forced updates
• Non-network updates (my TV allows USB or OTAerial firmware upgrades)
• Don’t connect your smart device to the network
• Decide you don’t need internet access on your car, or your fridge.

If you aren’t scared enough yet –

Cybercrime, the security of things : http://www.information-age.com/technology/security/123459847/security-things-iot-and-cybercrime

And don’t forget to patch your car : http://www.wired.com/2015/07/patch-chrysler-vehicle-now-wireless-hacking-technique/

Whois Craig Nicol

Since I took the John Sonmez blogging course, and started posting more regularly, I’ve noticed I’ve got a few more followers, so I’ve decided to join the WordPress blogging 101 course to make sure I’m keeping up the momentum and to try and avoid any common mistakes I might have made in the past.

Today’s topic is to introduce myself, which I hope is useful for those new readers, but it’s also a chance for me to focus on what I want to post about on this blog.

About Me

I’m paid to solve problems, usually in code, and usually in c#, with a bit of sql. I work mainly with websites currently but have prior experience with mobile and desktop development, covering JavaScript, C++, Java, Python, MATLAB and the gnu software suite to solve previous real world problems.

Solving problems is the part of the job that gets me up on the morning and keeps me motivated, but the problems that most interest me are the ones where we solve for the user. We don’t always get it right first time, because users often change their mind once they see working software, so part of what interests me is how we respond and improve.

I am a technical lead, so I am also interested in how to build and run a team.

Technology Choices

I tend to work mainly in C#, but you will find my blogging about a variety of technology topics, to see how well technologies and products out there solve the same type of problems I’m dealing with day-today. I’m looking for inspiration and warnings, and I’m sharing this blog publicly, both to help others think about problems this way, but also to get your input, so you’ll often find I finish a post with a question. That’s your cue to jump in.

Expect to hear about Node.js, XML, Big Data, User Experience, Web testing, HTML5 and beyond, security, debugging, requirements capture, Visual Studio, Yak Shaving, dynamic languages, managing geographically displaced teams, C#, Cloud development, agile, and other related topics.

Where Do You See Yourself?

Both the John Sonmez course and the Blogging 101 ask where I want this blog to go, and where I see myself next year. I want to present some of these thoughts at a conference, so consider these posts a first draft. I also what to get better at understanding the problems I’m solving, and how to continually improve my approach to them. I also hope I can engage with the wider community, by finding more blogs to read, more technologies to comment on, and keeping a wider pulse on the technology landscape.