In the end I went for a self-hosted WordPress instance. It’s just the easiest way to go – actively maintained platform, huge community, really easy to set-up and I could both configure URLs as well as redirections where needed. My bottom line is: I just need a place to write and publish.
If you find anything broken, please be so kind and let me know. I might have missed it.
Later I will likely take some time to design my own theme – simple, minimalist, content first. For the moment enjoy the visually excellent design by SiteOrigin.
“Copying Windows files”, “Getting files ready for installation”, “Installing features” … and so on. Installing Windows 8 is an experience pretty much the same as it’s ever been, where too much information is presented to those who don’t care, and not nearly enough to those who do. On top of that I’m informed that “my computer will restart several times.” Lovely.
Computers used to be the domain of hackers – people, who wanted to push the limits of what’s possible and know all about the machines they were using. Then the PC came along (or the Mac, if you’re that kind of fan) and all sorts of people strolled into the computer world, not always willingly. Most software changed along the way, but the installation processes were mostly left out of the changes.
Every piece of software – as big as an operating system or as small as an instant messenger – should have two modes of installation:
What we’re getting instead is usually a mix of both. Noobs find the installation process too daunting, to the point where they’re just confused and keep clicking “Next”. Freaks find it mostly unsatisfying, distrustful about the installer doing something they would probably not approve of. Nobody’s happy.
Think of installing software as the “unpacking experience”, like Steve Jobs always emphasized it, and Apple continues to do. It’s the first experience a user may have with your application and you want it to be as comfortable and pleasant as possible. Do your users a favor and design your installation process, just like you design your application.
Designed, developed, handed over to QA for testing. Then all hell breaks loose. “How do I test it?” “Where’s the documentation?” “This is broken; not it’s not, it’s not our component.” “I’m not signing this off!” Or my personal favorite: “I’ve other priorities to test now. I’ll get to your stuff tomorrow.” for three days in a row. Keeping QA separate from development teams is a recipe for trouble, friction and lots of missed opportunities. It has to stop.
Once you put a QA Engineer in the same team with developers, sharing the same manager, several things happen:
Sounds obvious if you’re an Agile zealot, right? Notice how I never used the “A” word? I didn’t have to, because the above ideas have nothing to do with the movement. Even Microsoft knew the value [PDF] of pairing developers and testers way before Agile was even manifested.
Testing is not separate from developing. It never has been, but today, when software requirements and markets change all the time, and so does source code, it’s more expensive than ever to keep a QA team separated from development. For the sake of your company’s success, stop doing that now.
Kanban is the last stage of software delivery evolution. Right now, at least, as evolution never really stops. The path is usually the same, starting with a disorderly “let’s just code”, moving gradually towards a waterfall system, then painfully stumbling towards a formal Agile framework, say Scrum, and once a Scrum team truly matures, they realize they’re really doing Kanban with a bit of unnecessary paperwork.
The jump from chaos to waterfall is rather obvious. So is usually the next step to go Scrum (or any other framework you like). We love all the Agile principles, user stories help focus on business outcomes, expecting changes makes Product Owners happy and programmers less stressed. Estimates made in story points help the management see when things will be done and ready, and make decisions based on that.
In Scrum for a new project you define a whole bag of user stories, estimate them, order by business value and call it a “Release”. That Release gets split into Iterations, each of 1 or 2 weeks in length. When you’re done with all the Iterations, you’re done with the Release and ready to unleash your product onto the general audience.
We’re often working, however, with software that’s relatively inexpensive to release. Like web applications, where you upload code to a server and all your users instantly get the latest version. There’s obviously the question of stability, quality and testing, but Scrum says strictly that the definition of “done” is “designed, developed and tested.” So, by that definition, you should have a release-quality product after every Iteration.
Add the two things together and you soon have a Product Owner asking you whether it’s possible to do an interim-release, before the whole scope is done. Sure, it is. It takes a while to work out discipline and processes right, so that the quality really is good, but once you’re there, you can release right after the Iteration summary meeting. And the Product Owner has a point: why do we wait another X weeks for the whole Release to be ready, when we can have something live now? Competition never sleeps and some of these things could make users seriously happy.
Here’s where Kanban comes in: once you’re ready to release after every Iteration, then the answer to “when will this be ready?” becomes “right after the Iteration you put it in.” Long-term estimations become irrelevant, as they always were anyway. Just because you have a user story planned for 3 Iterations from now doesn’t mean it’ll really be done there and then. Things shift all the time.
Why bother with the “Release” planning then anyway? Switch to a higher-level roadmap of changes, so that the team continues to follow a vision for the product, but plan actual work only for the next Iteration. Then release it immediately. Now you’re doing Kanban.
myguidie died yesterday. It was one of the few, sane ideas born a year ago during the 1st Startup Weekend Warsaw. Now it’s dead, and the only questions lingering are: what will @olasitarska do next, and what will everybody else do?
The startup scene in Warsaw, and Poland in general, is about to go through its first major trial. It started to heat up a year, maybe two years ago, with teams & ideas springing up everywhere. $1B acquisitions are a major inspiration and caffeine-laden parties like the Startup Weekend only add fuel to the fire. Now, when the toughest leftovers from the scene’s pioneers are failing, more and more people will start wondering whether to call the whole thing off and get a “real” job. I expect many will.
Here’s when the fun begins.
Business is tough. Really tough. You rise and you fall and your success depends on you being able to rise again. Fall seven times, get up eight, as the Japanese saying goes. And you can read all you want about failure being the new success and being oh, so great, such an educative experience. It still hurts like hell.
If you’re a struggling entrepreneur in need of a role model, here’s one for you: Rocky Balboa. “It’s not how hard you can hit. It’s how hard you can get hit and keep moving forward!”