Building A DNS Sandbox

I’m developing some automation around DNS. Its imperative that I don’t break anything that might impact any users. This post documents the process I went through to build a DNS sandbox, and serves as a crash-course in DNS, which is, like most technology that’s been around since the dawn of time, a lot simpler than it seems at first glance.

Continue reading

Posted in Uncategorized

Can Scrum Scale Down?

Prompted by a discussion on a LinkedIn group, I was reminded of a presentation deck I put together a couple of years ago to capture what my cohorts and I were doing for project management at the time.

Continue reading

Posted in agile, culture, efficiency, programming, scrum | Tagged , , , , , | Leave a comment

HP Chromebook 14 + Lubuntu First Pass

I’ve procured a new HP Chromebook 14. Chrome OS is nice, but I can’t code with it in any useful way. So I’ve opted to put Linux on it, the LXCE variant of Ubuntu (Lubuntu). And try a few other OSes while I’m at it. This post covers what I did, and my initial findings.

Continue reading

Posted in chromebook | Tagged , , , | 5 Comments

What does it mean to be a “python shop”?

Python developers: Do you call your team or business a “python shop”? If so, what do you mean? If not, why not?

Posted in Uncategorized | Tagged , , | 1 Comment

StringList – Is It A String? Is It A List? Depends On How You Use It!

At my job, I had an API problem: I had a object property that could contain one or more strings. I assumed it would be a list, some of my users felt that ['value',] was harder to write than 'value'. I found myself making the same mistake. So, I solved the problem, then I took the rough class I wrote and polished it. It’s up on my github, at https://github.com/jjmojojjmojo/stringlist

Continue reading

Posted in Uncategorized | Tagged , , , , , , , | Leave a comment

From Back Log To Ready For Work

Image

I’ve been thinking a lot about the backlog grooming and design process in Agile approaches like Scrum.

Something occurred to me recently: what I really want during this phase is true driving out of assumptions. I want to discuss and record implementation plans and discuss how we’re going to accomplish a given user story so that when we do estimation, it’s realistic.

A big part of that is the intermediate products, or project assets as I call them in the diagram – mockups, use cases, workflow (and other) diagrams, and prototypes. Proof of concept at various levels coupled with documenting the how of what we’ll do in the next sprint.

This diagram hopes to put this process, as I see it, into focus more directly than I think I could do through prose.

This is a mini-experiment of sorts – how much can I convey in a diagram without a lot of verbiage to accompany it?

As such, thoughts and comments are welcome.

Posted in Uncategorized | Tagged , , , , | Leave a comment

How To Become A More Efficient Programmer

A few basic concepts I’ve found essential in getting great work done fast.

Get Better Requirements Up Front

As the tough questions. Focus on driving out uncertainty, and testing assumptions.

The more effective you are at doing this, the less trouble you will have down the road.

Get Organized

Start recording and organizing requirements as they come in, and maintain your project documents in as orderly a fashion as possible.

This may mean using a lot of paper in a binder, keeping journals, or using project management software.

Yes, it’s extra work, but it’s necessary to avoid miscommunications and prevent missed commitments (among other things).

Keep the organizational work from bogging down your project by picking a method that’s easy for you to get into.

Then focus on getting really, really good at it.

I like to draw diagrams in LibreOffice, keep prose in ReStructuredText, and organize my work in SCM like git or a CMS like Plone. It doesn’t matter, as long as it’s something you can do with minimal effort.

Get Sign Off

Take the requirements you get from your stakeholders, reformat them, reinterpret them, and present them for approval.

Typically, this will start a dialog that will lead to better requirements, and solidify the relationship you have with your stakeholders.

Worst case, they sign off without reading it, and you have ‘rear-end coverage’ in the event expectations aren’t met.

Break Down The Walls

Resist the comfort of ‘buffers’ between you and your stakeholders and/or users.

Dealing as directly as you can with the people who your work will affect the most:

  • avoids unrealistic expectations
  • prevents false starts
  • limits rework

Overall, it means a shorter time to ‘done’, and happier stakeholders.

Work Iteratively

Prototype, refine, re-refine, prototype some more, refine, re-refine, ad infinitum.

Build just enough to meet the requirements, and then build more. Refactor liberally.

Further, don’t focus too much on polishing your work too early in the project. Start with quick proof of concept prototypes – move code from prototypes into modules as it matures, and add unit tests along the way.

It’s important to vet your engineering and design decisions early on to keep refactoring ‘cheap’.

As the project comes into focus, your APIs begin to settle, your namespaces take shape – then concentrate on kick-ass test coverage, modularization, code organization, DRY, packaging, and other refinements. The end result will be highly refined, well vetted units of code that can more effectively be replaced or reworked.

Lather, rinse, repeat.

Utilize Design Patterns

I sleep with the GoF book under my pillow at night.

Seriously, design patterns are not a magic bullet, but remember why they exist – because software is repetitive.

I’ve found the hardest part of any project is not writing the code. The real challenge is engineering the solution.

Design patterns lay out a foundation of practical approaches that have been tested both intellectually and practically, over time. They help us articulate a software problem – they act as a sort of solution vocabulary.

Building up a solution out of a series of design patterns means less engineering work, less communication parity between developers, and fewer engineering ‘near misses’.

Also, don’t forget there are design patterns in other areas besides OOP work – and sometimes, they’re not called ‘design patterns’.  For example, check out this repository of Enterprise Data Models.

Communicate Effectively

Absolute transparency coupled with free-flowing communication is essential to a healthy project… assuming that your stakeholders actually understand what you’re doing :)

It’s important to channel information in constructive ways, and tailor it to your audience.

You can avoid unnecessary re-work, bad requirements, and slow downs because of misunderstandings if you find ways to communicate completely, but effectively.

I like to send out periodic status reports, and keep in mind who will be reading them. But remember, this isn’t about spin – it’s about simple communication. Find ways to do it effectively, regardless of the underlying message, and you will get things done faster.

Find Your Community

Some of the biggest road blocks to getting a project completed are purely mental.

We paint ourselves into a corner, we become unsure about engineering decisions we’ve made previously, we get stuck on a problem we just can’t seem to work out.

Building a human infrastructure of cultural and engineering support can be one of the biggest efficiencies you can gain as a programmer.

Find a community of similar individuals. This may mean other developers at your organization, local user groups, IRC channels – be creative. The similarities might be surprising – usually that means similar languages, industries, domains, platforms, but that’s not the case all of the time. Don’t be afraid to seek out non-technical connections.

Keep in touch with coworkers from past jobs. Utilize social media, IRC and sites like StackOverflow to present questions to a broad audience.

But never forget to return the favor. Keep a blog and update it frequently. Answer other people’s questions on IRC. Building a reputation for being helpful will help you get help more… um… helpfully. The more help you can get, the less time you’ll spend in mental quagmires, and the more efficient you can become.

Posted in culture, efficiency, programming | Tagged , | 2 Comments