When I worked for the State of Wisconsin (as a contractor), I had many great conversations with Mark and Jon about agile software development.
One day I wrote down a list of 25 thoughts on risk management and testing. Eventually I’ll weave these ideas into articles, but for now, just a <ul>
* Everyone contributes risks
* No risk exists without probability and impact
* No impact is infinite
* All impacts are measurable
* Risks drive level of design
Posted in software development methodology | Tagged agile, requirements, risk management | 4 Comments »
Please banish the use of the word “Requirements” from your software development lexicon. Immediately.
For many software teams the requirements document is the king of documents.
You know the routine. The software team works with the customer (or customer proxy) to put together a “complete” list of “requirements”. Once that is done, the team writes the software implementing the requirements and voila! the project is done.
Or maybe not.
Posted in software development methodology | Tagged agile, features, requirements | 2 Comments »
It isn’t just Ruby on Rails login forms that are broken. The majority of login forms on the internet are fundamentally broken.
In what appears to be some form of risk management strategy, these login forms introduce a different risk to the websites that use the default behaviors – in RoR sites, this is often either AuthLogic or RestfulAuthentication.
Both are broken in a big way.
Posted in software security, software usability | Tagged don't do this, risk management, ruby on rails, security, usability | 8 Comments »
The other day I subscribed to a daily newsletter from a new “social media” website. This is a NEW website – they have just become beta. They’re not big, they’re a small startup.
I tried to reply to one of the emails they send each day. And I quickly discovered they send these using a no-reply address. Meaning I COULDN’T reply.
And that broke my brain. This is a company which is all about web 2.0 and the new communication mechanisms available. Yet they have broken the single most used communication process of the internet!!! Why would they do this? People have been sending and replying to emails for decades now. Decades. And it works.
Posted in email | Tagged customer service, email | Leave a Comment »
Almost on queue, Twitter has recently done (twice!) what I’ve been thinking about lately. They have removed features.
Removing features is very tricky and fraught with problems, even if those features are used by very few people.
Posted in software development methodology | Tagged don't do this, features, twitter | Leave a Comment »
So the twitter changed their notification emails for when someone follows you. And they are definitely an improvement over the old notifications.
But they are broken.
I’ve read several articles talking about the “richer, HTML version” of the email. Richer? What year is it? Formatting doesn’t make something “rich”, data does.
Data is rich, markup is lame.
Posted in programming, software usability | Tagged features, twitter | 1 Comment »
I was messing around with the new Photoshop Express gizmo today and I clicked the help link.
It opened a new window to this page which looks like this screenshot (for those who dun wanna click.)
Posted in software usability | Tagged don't do this, usability | Leave a Comment »
Posted in software security | Tagged risk management, security | 1 Comment »
With gmail and fastmail, and other email systems, you can use plus notation to keep track of who is passing around your address. When I sign up for something online, I’ll often use myaddress+domain@fastmail.fm as my address. This address simply works and I receive the wanted email. If they sell/hand over my address, then I’ll know – and there would be hell to pay.
Posted in programming | Tagged don't do this, email | 2 Comments »
Often reading, thinking about, or doing risk management, software, economics, snowboarding, running and/or ping pong.
