What we do isn’t magic.

It can be time consuming, tedious and boring. It can also be entertaining, challenging and exciting. But very little about it is beyond the capabilities of a moderately intelligent person.

Every time I tell someone I’m a software developer they react the same way, “So you’re some kind of genius”. I don’t have the heart to tell them no.

There are software engineers who are geniuses, but that doesn’t make it a prerequisite of the job. We like to feel special, like we’re above the dirty peasants, but what we do is actually pretty simple. I’ve always thought the best analogy for what we do is language. In language you learn syntax, grammar and structure along with a list of words and phrases. Programming is a lot like that, so much so that I would argue anyone who can learn a second language could easily learn to program.

There are no chants, no secret handshakes and no alchemy needed. Instead it’s a simple and straightforward method of providing instructions, mostly in plain english, and getting predictable and repeatable responses. If I say “get me a sandwich” the computer either understands what I’m asking for, and gives it to me, or tells me it has no clue what’s going on. That’s a better response than I get out of most people when I try to get sandwiches out of them.

Does that mean everyone who can program would make a good programmer? Definitely not. It’s an analytical job that requires an analytical mind to do well. But there’s another industry secret that needs to be mentioned. A lot of programmers do just fine without ever being good. If we limited programmers to just those who could perform well, write clean code and think on their toes we’d have to slow down on the software/tech boom we’re in right now.

The world needs mediocre programmers too. God knows I’m not going to spend my life maintaining legacy java apps so please, feel free.

We shouldn’t hide the fact that what we do isn’t magic. It bites us in the ass more often than not when management thinks we’re magicians anyway. Instead we should encourage people to take a look at programming and realize, really, it’s just another language.

In some situations the architect may be replaced by a generic manager, but I will state straight out that if your manager is not/was not a developer in their career, you’re better off letting your developers fill the role ad-hoc. The architect has to be able to see all the angles, but without a strong technical background it is nearly impossible to understand the development position.

The architect ultimately makes decisions and argues the case of the development process to any interested business units. It is a particularly demanding job requiring a mix of political acumen and people skills.Prioritization – Step 1

The Architect works out a plan of attack with The Analyst. Generally this is where a high degree of technical knowledge comes in handy, as The Architect will be able to provide ballpark estimates of the comparative difficulty of features up for prioritization.

Remember, nothing is written in stone in terms of time at this stage, but it is useful information to have for prioritization.

As always prioritization is based on business needs first and foremost.

All the rules still apply from The Analyst’s prioritization steps.

Specification – Step 3

The Architect will play any number of important roles during the specification process. As stated in The Analyst the story planning procedure involves all the major players, and may include everyone if the situation calls for it.

The Architect’s responsibilities in the planning meeting will include settling disagreements, facilitating discussion and ultimately making the call if multiple technologies are on the table.

First and foremost the architect is there to make sure all sides are communicating clearly, and to ensure that the vision comes together in the end.

Agile teams are generally fairly self-organizing, and with a bit of leadership a good architect can point his team in the right direction and get everyone working on the same page.

The Architect must above all adhere to the principals and methodologies of process. The buck stops with the architect when it comes time to defend process requirements to the business at large.

Step 3 – Iterations and Review

Much like step 2, The Architect makes certain that the process is handled respectfully by all sides, and that everyone remains on the same page throughout the process.

As features are added The Architect may also be called on to push back when a feature can not reasonably be accomplished and will require an extension to the deadline, or a postponement to a future set of improvements.

If the corporate culture does not allow push back where it is appropriate within the process then the process itself will not function correctly. While a lot of people will talk about a compromised agile the realities that agile is designed to deal with are not able to be compromised. Time does not suddenly stop so you can add more features and there are only two ways to add features that exceed any padding you might have in your schedule.

#1 Demand overtime from your developers. This can be used on occasion, but costs you developer good will and inevitably costs software quality.

#2 Accept significant decreases in software quality by the removal of processes such as test automation that are absolutely essential to doing software well.

Neither of these should be considered acceptable except under the rarest, most dire of circumstances (meaning that delays will cause severe legal or financial difficulties potentially leading in company dissolution).

Post-release – Step 4

After the software is released The Architect will continue a cycle of prioritization and story management with The Analyst per a normal maintenance cycle.

Conclusion:

While the role of The Architect is not as hands on as some of the others it does require a singular viewpoint. The Architect must be able to accept the input of every single individual involved in the process and sort those opinions into useful, informed decisions.

The Architect also stands the considerable risk of taking heat due to deadlines missed, features cut and the like.

That being said, The Architect is key to making sure that the process works. Without someone spending the time, energy and effort to keep a software development team on track it is easy for disagreements over topics like “Is this a bug or feature” and “Can this be added by deadline” to turn into squabbles. The Architect manages the needs of the project while keeping the process first and foremost in his or her thoughts.

Agile does not mean “I know you just launched this yesterday, but I need you to add a few features by tomorrow”. We attempt to create a workflow, to get input and feedback in a constant loop from users, and to never need to push out features that are created under highly undesirable circumstances, such as all nighters ending in a early A.M. release.

Why? Because those circumstances suck for the code quality, the developer and ultimately for the business. Bugs are introduced, mistakes are made and sometimes tiny, hidden inconsistencies can create very serious results. The process is not there simply to make us happy, it is there to make what we produce better.

The reason for this rant is that I’ll be using the word agile a lot more in this and future posts in this series. I wanted to get that out of the way before I started.

On to the Business Analyst now.

Introducing The Business Analyst:

The position of the Business Analyst (BA) might need a little explanation, not only for people not used to working in structured environments, but also for those used to working with a traditional marketing team for their software concepts and design.

Even if you have a marketing or product team, it is important to think of them as a business analyst, and get them thinking in the same way.

The business analyst serves as the first line of communication, along with a critical eye as software progresses. The role I will define for them here is outside of their normal scope, but has its reasons.

The Idea – Step 1

As explained in Part 2 of this series, the users must be trained to present a problem to the software team. This is where the business analyst comes in. It’s a very simple process, the business analyst has a brief meeting with the user to discuss the user’s problem and needs as well as to begin the process of requirements gathering and to get an understanding of the businesses needs as they relate to the suggested features.

Prioritization – Step 2

The Analyst should now understand enough of the problem to provide the Architect a rough idea of the requirements, and they (and any other relevant business units) can discuss prioritization. At this point the story enters the backlog of requested stories/functionality, and is processed when its turn comes up.

Specification – Step 3

There is absolutely no value in carefully defining software criteria months (or even weeks) before the first line of code is written. By the time you get to the code base, the requirements have likely changed. Once the story’s time comes up and it is ready to be moved into an iteration/sprint then you can go into story planning.

Story planning involves a significant number of actors. The User is strongly desired for the relevant planning of their feature set, but not required. Required participants are The Analyst, The Architect, The Developers and The QA Engineer. If relevant you should also include The DBA and The Designer as they will play an important part in estimating complexity.

The story planning procedure can be complex, particularly with so many actors in play. The Analyst’s role in this particular segment is fairly complex. The Analyst is there to organize the meeting, run the projector that displays the stories (if anyone is still using pen and paper backlogs…just stop it) and perform any actions taken against the MMFs.

The point of this meeting is to review each MMF proposed for the upcoming iteration, break each one down into a number of User Stories and Tasks and ideally provide a scenario for each task that contains a clearly defined piece of functionality (features, not chores) stated in the Given/When/Then syntax, which can be executed as a test later one.

The common argument here is that this meeting is very expensive because of the number of actors in play. It is important to understand the point of this sort of detailed story planning. Every single person who comes out of a meeting like this will know exactly what was planned, exactly what is intended and often through natural discussion the why of it, and it will reduce both friction and confusion down the road. If the user can be involved, that’s great as they start thinking right from day one about what they might need to change!

Iterations and Review – Step 4:

The role of The Analyst in these reviews is passive. The Analyst is present, assisting with the definition of new requirements if they come up, but for the most part this is a meeting run by The Architect, with participation from The Developers for the sake of The User. QA should also be present.

Remember, these meetings are for The User to stay focused on whether or not the software meets their needs!

Acceptance – Step 5:

The Analyst should ensure that all acceptance tests run and that beyond the functions of QA the basic functionality meets requirements. As each individual User Story is completed, The Analyst should perform acceptance to ensure the business requirements are met. This can occur before or after QA, but ideally it occurs in parallel with.

Post-release – Step 6: 

The Analyst should keep an ear open for any feedback after the release, and through the continued upkeep of a software product. Often The User, now acquainted with The Analyst from working together, will speak to them freely about the software platform they work in. These relationships will be great building blocks for improving communication and workflow as continued work on a software product goes forward.

Conclusion: 

The Analyst’s role is not a minor one, and the part he or she plays in initiating relationships with users can not be understated.

Commercial software in particular makes use of user advocates like product specialists and business analysts. Their job is to behave for certain parts of the workflow in the exact manner that an enterprise user might behave when internal software is being built. Beyond this introduction I will refer simply to the user, which will refer to whichever is applicable to your situation.

The User Timeline:

The user is involved in nearly every aspect of the ideal software development lifecycle. By involving the user all the way through, with no long gaps in user interaction, a software team is able to take a more agile approach to development and changes.

Because of this, the user has the longest timeline of anyone, they see the start and finish of the software development lifecycle, and continue to partake in it even after most of the software team has moved on, providing information for improvements, bug reports and the like.

Starting with the problem – Step 1

Software solves problems, it’s that simple. Whatever the problem is, that’s right where the user comes in. The user’s responsibility is to be able to define the problem clearly enough that the business analyst can own the project.

Users should be encouraged to come to the business analyst with clearly defined problems, not clearly defined solutions. There are a few reasons I say that, but the main one is that the business analyst is more prepared to offer software solutions to problems than the user is to come up with them.

Not only will the user potentially offer solutions that are not immediately actionable on their own, but they may also offer a simplified version that doesn’t do everything for them that it could, instead relying on extra manual processes that aren’t actually needed. The software development team is there to offer solutions, and to help the user make as easy a transition from whatever their current solution is (if they have one at all) to a new, improved solution.

Defining the solution – Step 2

At this stage we have a little bit of choose your own adventure. This section will be written as if the user is too busy to take part in the test case development and feature clarification, however, it is ideal if they can take part. If a user is capable of taking part in these procedures, please see part 3 in this series and have the user take the role of the business analyst for the section Specification.

Given that the user is not able to help define the tests.

When the tests have been defined

Then the user will review the user will review them at their leisure

It’s really that simple. At this point I can’t avoid the very real need to use Gherkin style language, or something enough like it that the user can read and understand what functionality is being tested, but we’ll talk about that more in part 3.

The user should review the tests to at least ascertain that the software development team is heading in the right direction and that no major functionality is missing right off the bat. This will be the first chance for the user to interact with the software process directly, but not the last.

Iterations and reviews – Step 3

Other things have been happening in the background while the user waits, and now there’s something to show. I’m going to say ideally that the meeting I’m about to describe should happen weekly, but bi-weekly iterations are not uncommon. Anything longer than bi-weekly and you start to lose the advantages of being able to make a rapid shift in development.

As each iteration comes to a close the software development team will gather. This meeting serves several purposes, but for the user the purpose of this meeting is singular. To see the software and get a real time demo of what it does. It doesn’t matter if the software team only has a skeleton of a page with some checkboxes on it.

This meeting will serve to keep the user constantly in the mindset of the software that they’re having developed, it will keep them thinking about the direction it’s heading, and it will help ensure that needed changes are caught prior to release. This regular demo of the software development process is absolutely vital to keeping the user in the loop.

Yes, this means software developers who are working on the project will interact directly with the user. This serves a lot of purposes. This actually comforts the user to a degree, but it serves a greater purpose which we’ll talk about in another segment.

Acceptance – Step 4

By this point the vast majority of changes have already gone in. The user already knows what the software done, has seen it run at the end of every iteration, and should, thanks to the weekly/bi-weekly demos, understand every decision made about the software. Acceptance should go very smoothly, with only minor changes now that the user is directly interacting.

At this point the user will make usability requests, these should be simple and easily handled by the development team.

At the end of acceptance the software passes into QA and the user should not see the software again until release.

Conclusion:

As stated previously, a user advocate of some type can fit in to the user role acceptably, though doing so means that to some degree the software development team owns the entire process, which is not really ideal.

Also, although step 2 was written from the more realistic perspective that a user would simply review the acceptance criteria written, this is not ideal either, and reasonable attempts should be made to include the user in the initial planning meetings which will be talked about extensively in the remaining segments.

Internet Explorer has started to gain a small following in what I can only guess is some sort of developer-hipster hybrid community, and I’ve got a bone to pick with those people.

Internet Explorer 6, which born in the summer of 2001, and still exists as a force, albeit a shrinking force, in the world of website design. There have been three new versions of Internet Explorer released in this nine years since.

That’s my history lesson.

But the real thing to counter is the claim that IE9 being better means it’s cool and hip to use IE again! I’m not arguing that IE9 is better, not at all, but I am arguing against its use anyway.

If tech geeks and power users start losing cohesion on the “anything but IE” mindset, the war against the terrible force that is Internet Explorer will falter. Script kiddies will stop seeing IE as forbidden, power users will stop secretly switching all of their family’s desktop icons, sons will no longer tell their mothers that IE causes angels to cry!

I get you have to use it for work because you have to test against it, that’s not the problem I want to address. Just those people who have decided IE9 is an acceptable solution for browsing when they don’t have to.

So a few reasons why I want to keep arguing against it, and why we as a community of nerds and programming junkies should keep up the good fight.

#1 It’s still not right

You can argue ’til you’re blue in the face, but there’s still a lot of things missing from IE.

* Forms Validation

* Web Sockets

* Spellcheck

* HTML5 History

Don’t try to argue with those. Those and many more additions are all listed as new in IE10, which will be released along side Windows 8, and will be Windows 7 and 8 only.

#2 The upgrade cycle

A lot of people like to bemoan the upgrade cycles of Chrome and Firefox, especially those people who have hopped on the IE9 train. I feel your pain, I really do.

But worse than a too fast cycle that sometimes causes addons to stop working unexpectedly?

A cycle that is laboriously slow.

Now, that slow development cycle might be great for a corporation with a locked down update policy (and we’ll discuss this some other time), but for personal use and browsing that means a long gap between major features being released. How long?

Well, IE7 was released in October of 2006, five years after IE6. IE8 was released in March of 2009. IE9 wasn’t released until March of 2011. All in all a decade of web development saw only four major editions of Internet Explorer.

Why is that bad?

Frankly the web moves faster than that, and so does technology. Don’t agree? I can’t help you. Javascript has been a mainstay for years, and it didn’t get to a good state until IE9s release earlier this year.

#3 Fragmentation

IE almost encourages a kind of “This is my version” mentality from users. They click “Don’t remind me” when windows prompts them to update. I don’t know why this is, and I try not to think about it too much.

You can’t break this habit. If it was possible to get people on the latest IE and get them to upgrade when the time came, I’d say great! But it’s not.

IE6 and IE7 combined still make up about 25% of IE users. Even windows XP users can upgrade to 8.

Conclusion

The goal should be to continue to break the habit of IE use. Nothing about Internet Explorer is going to change long term, they will maintain a enterprise-comfortable update cycle and fragmentation will continue to be an issue.

Just let it die already.

And it is totally not for me.I admit, I have a terrible habit of speaking my mind. I have sometimes outlandish opinions. I often want to modify processes that I feel are either inefficient or philosophically incorrect.

I want to make things better.

Projects can go a long way with a steady group of non-offensive nose-to-the-grindstone developers. Things get done, commands get followed without question. And things stay the same.

Little annoyances stay little annoyances. Pain and friction points stay painful. Nothing changes, or changes so slowly that no one is around long enough to see the changes start to finish.

Being just another developer is anathema to kaizen.

I know, that’s a bold statement. It’s also potentially offensive to any numer of very talented, very smart people who just don’t see their work as something to get stressed out over.

I’m not trying to be insulting to those people. I don’t question their talent, intelligence or skill.

I have it in me to stress out. I have it in me to hear, “But you’d have to get buy in from everybody else,” and think, “Sure, why not?”

Yeah, changing things can be a lot of work. Putting yourself out there can be a huge risk, especially if you put yourself out there for something that doesn’t pan out. It’s a huge risk with no measurable reward.

I wouldn’t suggest it to anyone.

But I doubt I’ll ever change my personal outlook on it. I take too much personal pride in pushing forward the best changes that I can.

Why does it matter? Because how we communicate internally matters a great deal.

Features: 

Features are things we haven’t tried before. Completely new code and functionality. It’s not hard to define, if you’re going to create whole new methods to accomplish it, it’s probably (but maybe not always) a feature.

Why it matters?

Because features are both billable and require a significant commitment from the whole process, including brand new automated testing, potentially new database work, brand new requirements gatheirng.

Features are usually the most expensive type of software modification. That means that in companies where money is important features usually need the most consideration of cost vs. gain.

Enhancements:

Enhancements are modifications to the behavior of existing functionality. You have a list and you want to change the way it sorts? After save the page redirects to home instead of show? These are enhancements to the existing workflow.

Why it matters?

Enhancements are nice to have, generally they fill in user expectations that were not part of the initial specification. Enhancements are relatively cheap compared to features, usually requiring modification to existing code structures, existing tests and existing specs.

Bugs:

Bugs are non-specification meeting behaviors that exist before release. Why before release? Because bugs are registered by whoever is doing QA or acceptance, and are fixed before they reach a production server. Bugs can be extremely contentious when specifications of behavior are unclear.

Why it matters?

Bugs are things we’ll get to before release. They are fixable, and it’s good to be aware of them. They are rarely an all stop, the exception being if QA can not move forward due to a bug. Bugs are best prioritized as the next thing worked on after the current in progress work is completed.

Defect:

You can probably see where this one is going. Defects are bugs that made it into production. These are customer affecting because the customer is the one telling you they’re there.

To some people defect is a dirty word. Does it hurt you or your team’s pride? That’s good, it is a sign that something was allowed to get through.

Why it matters?

If a defect gets logged it means that the impact needs to be immediately assessed and may mean an immediate fix and release. Defects are extremely costly as they cost not only the money to fix, but to get back into what you were doing when your day got interrupted. Defects also cost reputation, as the users are far more likely to remember what went wrong than what goes right.

Conclusion:

Yes, it matters. No they are not all just Change Requests with a priority. If you make a habit of treating a new piece of functionality the way you treat a publicly available defect then your process will run the risk of breaking down to whims. Yes, you can argue, changes are lower priority change requests.

Until someone decides they absolutely need that feature for the software to matter to them.

If your entire software team is focused on a extremely narrow, constantly defined user base, you might be able to execute change requests as a thing unto themselves.

Otherwise, even with internal software, you have to actually weigh the cost and realities of software improvements.

We interrupt your regularly scheduled program to explain what this is. If you feel the information expressed in this interlude is incorrect, you probably won’t enjoy the rest of the series either.

My opinions are all based around the concept that no portion of software development is contained within its own bubble. Every piece must be interconnected or communications breakdowns will always occur. I won’t bend on that point, and I won’t deviate from it. There may be other and even better ways to keep things flowing, but they must flow naturally.

Things to get rid of – 

1. Handoffs: There is no such thing as a handoff of work. Handoffs mean a break from one workflow and the entering of another. Handoffs are like code smells, there may be a reason for them, but they’re a sign that something is wrong.
2. I-people: I-people or I-shaped people are singular specialists. I strong embrace, and encourage others to strongly embrace the concept of T-people at all phases of development. It’s not enough for software developers to know a little bit about the business and a little about QA, but QA and Business have to embrace the concept as well.
3. Manual Processes: This is another smell. There are some manual processes we can not avoid, but any that we can, we should. Computers are great, they do exactly what we tell them to, but like always GIGO. If we make mistakes because we’re manually repeating a process, then bad things happen. Manual processes are the enemy. Exterminate them.

Things to embrace –

1. Continuous Workflow: From the moment an idea comes into inception it should enter the development workflow. This idea would be vetted by the business unit, crystallized and naturally flow into the other processes, which will be outlined in detail. The workflow is not bunch of individual stops in committee, it is a river of ideas.
2. T-people: There is no reason for someone to have their head buried in one subject so deeply that they aren’t even aware of ancillary concerns. This series will deeply cover how to expand the understanding of each and every business unit. across the breadth of the software lifecycle.
3. Automated Processes: There is no single business unit that escapes the advantages of automation and computerized tracking. Putting in the right tools and using them correctly will drastically reduce friction, embrace an easier life.

Warning: All of the following statements, along with the additional entries I’ll make on this topic, are based on personal experience only. While experiences may vary drastically, this is my viewpoint on how development teams can be organized in a manner that will provide the best results and cause the least amount of friction. Opposing opinions are extremely welcomed. This is the first part of a multi-part series.

A development team consists of many parts, and part 1 of this series is going to be dedicated to defining those parts and  talking about their traditional functions. The next section will focus on altering those traditional functions to fit more inline with my viewpoints on the proper structure. In the third part we’ll talk about creating a frictionless transition from the traditional to the non-traditional.

Sometimes multiple parts of these functions will be performed by a single entity, in these cases treat them as two distinct job descriptions being performed simultaneously.

Now, the functions of a software team, in the order their responsibilities will be covered is:

The User

Software is not often built on the premise of pleasing yourself. Software is developed for use by an end user be it other software developers, internal members of your company or consumption by the public at large. There is always a target customer for software production of any kind.

There are two ways in which customer interaction can be performed. The first is through a user advocate, which is ideal when you are dealing with a piece of mass consumption software while the second is through direct contact with a stakeholder. The interaction should not vary much between the two. Both speak for what the product is designed to do, the goals it needs to meet and what defines a finished product.

Product/Business Analyst

This person or team is responsible for  interacting with the Stakeholder and turning concepts into actionable items. Their job is to somehow get a stakeholder to understand what they want in terms that can be turned into software. It can be an extremely difficult balance.

One of the primary differences between Product teams and Business Analysts are that Product tends to operate independently from the software development team, acting more like a think tank in some cases, while Business Analysts generally exist as part of the development team itself, providing a friendly face and a users outlook to development teams.

Software Developer

The role of the software developer is fairly straight forward. They take on the specifications of the product team and translate them into logical code. Where the difficulty can come in is that a manual process is often full of vagueness and indefinites. Computers don’t understand stories like “Evaluate length of customer contract vs. unique circumstances”. Everything a programmer works with must, almost by definition, be quantifiable.

In addition the Software Developer provides tested code and works to improve the development process to increase efficiency and throughput.

Quality Assurance

QA is one of those hard to define portions of the process. There are different definitions and concepts that all fill the same general position in a software team.

Generally the responsibility of quality assurance is to ensure that all the necessary requirements of the software as met as well as the esoteric concerns like usability,

In many ways Quality Assurance can be seen as one of the most complicated tasks on a software development team, requiring both left and right brain thinking.

QA Engineer: The QA Engineer is a subset of QA, generally focused heavily on automating tests and minimizing the usage of manual tests. QA Engineers are a more heavily technical style of QA.

Manager/Architect

A manager handling a software team is in the unique position of having to handle the friction between team members with very different goals.

While technically the whole teams goal is to create software people want to use, it is not uncommon for the business units in question to come in to conflict. When this occurs the manager must handle those conflicts keeping in mind the singular goal of producing the highest quality software that they can, regardless of who wins or loses in a disagreement.

###UPDATE###

Infrastructure

These are the guys and girls who give you the servers you need to move between environments. Their responsibilities might include picking what linux you use, managing your firewalls and generally serving those tech needs that require a deep understanding of concepts like network management and host level access.

Data

No, not everyone’s favorite android.

The data team often handles schema definitions, database backup schedules, permissions and indexing along with a number of other details. A database administrator can provide a wealth of knowledge on performance tuning at the data level, along with providing quick access to statistics and measurements that the business units will find extremely helpful.

Design:

Designers, how could I forget them? They make the work we do beautiful. Designers are generally creative people who have a huge influence on what goes on an individual page, and how it’s placed. Their work can be key to the success of a project, especially a commercial project.

Designers often write the markup and CSS key to web applications, and even .net desktop applications have found a place for full time designers with applications like Expression Blend and frameworks like WPF.

###END UPDATE###

In Conclusion – But not really

Even this short list of what the core team does (and I get the nagging feeling I missed something) is running a little long. Keep in mind these descriptions are by no means complete, and cover only the most basic of job functions.

In the next part I’ll talk a bit about modifying these traditional roles. My original hope of keeping this to a three part series might be a little optimistic. We’ll see where it goes! If you feel anything is fundamentally missing please let me know so I can consider adding it as we get into the series.

Get Prometheus.js to 1.0

This is huge. I will do this one.

Learn Python

#BecauseICan

Convert my Blogs to CppCMS

I’ve been wanting to go custom on this blog, and if I do, why not add CppCMS to my toolbox.

It should give me something unique to write about.

Besides, I’ve always wanted to push up a git commit to the effect of “Fixing that annoying segfault when a user double clicks post”.

Seriously, nothing on the web is double click, just stop it.

Get Prometheus.py to 1.0

Here’s hoping.