Constraints for Devs and Managers
The sheer amount of options that developers have is staggering. Software language, platform, and frameworks are all big choices that developers have to make. And they think they love it. They think that they’re in a smorgasbord of choice and that it’s the greatest thing ever. But it’s not. What they don’t realize is that if they had fewer choices, their code would be better, the end product will be better, and they’ll be happier.
Make Your Own Constraints
If you’re in the type of job where you create the same thing over and over, then you need to start making your own constraints. Don’t worry about all the possible ways you could do something. Cut out most of the options and solve it using a self-imposed set of constraints.For example, when LINQ first came out, I had a new project that was fairly typical. I told myself that this project was going to be done without using T-SQL stored procedures. I was going to do all the data access in LINQ to SQL in order to learn how to do it. Some things were big challenges. I was so used to doing complicated T-SQL patterns in stored procedures that I had to force my brain to relearn how to do what had become simple tasks. But it was worth it. Not only did I learn LINQ syntax and some of the more complicated joins, but I had a good time. I made my own job more interesting. It probably took longer. But the long term payoff was greater.
Do You Run a Group of Software Devs?
If you’re the guy in charge, you need to keep your devs interested. They can get bored easily and if you’re not challenging them, they might want to move on. If the type of work you do is often regurgitated over and over, then you need to create fake problems for your engineers. I really mean it. Fake problems. Don’t tell them they are fake problems, though. Just tell them that, oh by the way, the internet pipe to that client is only online once every hour for 2 minutes. It sounds ridiculous in this day and age, but it will force your engineers to solve the problem creatively.They also like to be tricky. If you’ve given them a problem with a loose set of fake problems, they will naturally try to work around a problem and just might inadvertently solve a different problem. Since the constraint is fake, you don’t really care if they worked around it. But you just might get something you weren’t looking for, something you can use later, or some new technology or feature upgrade to put in another product or sell to another client.
By focusing their logical minds on solving a problem, you will be allowing the creative side of their brains to open up and solve other problems in new and interesting ways. Engineers love to solve problems and if there are no problems to solve, the stagnate and get bored. Don’t let your engineers get bored.
Frameworks Are Your Friends
Software Devs can be like kids sometimes. And anyone with a kid (hopefully) knows that you need to set boundaries. Boundaries are good for the kids because it lets them play securely within the boundary. They know, “as long as I’m in here, I’m safe”. And the same applies to software devs. Give them a framework to play in that is smaller than the full range of possibilities. Language frameworks nowadays can be quite large and that can be overwhelming. But if a developer knows that they can only use a certain subset of the entire framework, there’s less to keep track of.An inexperienced dev might work on something thinking, “I wonder if there’s a better way to do this that I just don’t know about.” And there might be. But if you limit their set of tools, it will be clearer to them that the solution they came up with is in fact the best way to do something. An anxious engineer is not a good engineer.
I’m not saying pretend jQuery doesn’t exist and make them recreate it each time. But maybe say, “Time spent downloading JavaScript frameworks must be less than 50 ms.”. This will force them to limit the sheer amount of JavaScript they include in the page which will limit their toolset. And you never know. They might just come up with something awesome.
Design Guidelines
If you’re designing for a specific platform that has a set of design guidelines, thank your lucky stars. Mobile platforms such as the Windows Phone and iPhone have published guidelines on how an app should reuse existing navigation and design guidelines. This helps ensure that the user experience is consistent regardless of the app. Android, on the other hand, does not have these guidelines, so a developer is left to their own devices. And often those devices are wrong.Just getting started on Android can be harder because you don’t necessarily know where to start. At least on the other platforms, you have certain ground rules that you should follow and following those rules makes development easier. Sometimes, not following the rules will keep your app from being certified. If you don’t have a designer on staff, you don’t necessarily need one. The platforms have already employed designers who have made some guidelines for you. Follow the guidelines for design and focus your energy on what you’re good at.
Write Good Software
Regardless of the constraints, write excellent software that is simple, easy to debug, and clean. Spend more time on the code you do write, and less time worrying about what you didn’t write. Limiting the sheer volume of what’s available will help accomplish this.Photo courtesy of Flickr user edwbaker.