Microsoft released Beta 2 of Office 2007 on Tuesday, and I decided to give it a try. I’ve not been using it long enough to make a real judgement about it, but my initial impressions are quite positive. It’s still quite rough in some places, but the overall experience is pleasant enough.
Installation
Probably the biggest problem I had was getting the thing installed. Installing the Professional Suite took quite a long time, and I had to fiddle around to get everything working properly. Outlook in particular was a pain, because the installer didn’t uninstall the previous version despite me selecting the option. None of the problems I encountered were catastrophic, but they all added up to make me quite annoyed.
The other main problem I’ve had is with Windows Desktop Search. I’ve had no luck getting it to work, so I’ve decided to give it a miss. I’m a bit annoyed that Outlook requires it for the Instant Search, but search folders still work so I can live without it for now.
I’ve not had time to give everything a thorough going over, so I’ll stick to what I’ve spent the most time with.
OneNote
Unfortunately I’ve not had a great experience with OneNote so far, but I’m putting it down to a hardware / driver problem on my machine. The mouse has a habit of jumping around the screen, and then the app crashes. This has happened to me with other apps, so I’m not blaming OneNote. It’s a shame though because it looks like a really cool app.
When it has worked, I’ve had chance to play with copying text from images and jotting down notes about various subjects. I have a feeling it would be a great tool for organising blog posts, so I’ll definitely be giving it another shot when I get a new computer.
Excel
The first thing you notice with Excel is the Ribbon. Seeing as it’s in a few apps, I’ll talk about it in detail later, but for Excel it really makes you feel like you’re getting more. You can see a lot more functionality without digging around too much, and the new tooltips explain features a lot better.
I mostly use Excel for scheduling time on projects, so I haven’t seen most of what the product has to offer. I’m sure I’ll have a better idea of what it can do over the coming weeks, but for now it does it’s job and that’s all I can ask.
Outlook
I use Outlook every day, so I was a little anxious about replacing the original with the Beta. It’s been a mixed bag so far, and I’m not completely convinced.
The new To-Do bar is a nice addition, and it gives you a good overview of upcoming tasks and appointments. I’ve found it much more useful than “Outlook Today”.
There seem to be a few tweaks email wise. You can quickly assign a category to emails, and flagged emails show up in the To-Do bar. The task and calendar sections have also been improved. None of the improvements really stand out yet, but they all add up to a more pleasant, tighter experience.
Performance wise, I’m a little disappointed. I don’t exactly have a powerhouse of a PC, but for me Outlook is the most sluggish of all the new Office tools. It freezes for a few seconds whilst switching emails, and can freeze for quite a long time for no apparent reason.
The interface for composing emails benefits from the new Ribbon, but it’s not so useful if you’re a fan of sending plain text emails. If you want to get a little fancy though, it looks like it will be a big help.
Word
The first thing that really struck me about the new Word is that it looks, well, nice. I realise it’s only a word processor, and that looks are secondary to functionality, but it’s always nice to enjoy using a piece of software. My first impressions were definitely positive.
Of all the programs out of the new Office that I’ve used, Word certainly feels the most improved. It’s still a little bit ropey in places however, particularly in some of the older dialog boxes. The overall experience is very slick though, and I’ve found that the new appearance and interface alone makes me feel more productive.
Styling the document is a breeze, and the “live preview” feature is more useful than I imagined it would be. Simply hovering over styles in the gallery will change the selected text. This is nice because you can see how the style will look without having to worry about ruining the document if you don’t like it.
Not all the improvements are as big as the ribbon. The status bar at the bottom lets you change the view and zoom level quickly, and also displays the current word count. Nothing spectacular, but it’s a welcome improvement.
It’s not all good though, and one feature I was disappointed with was the blogging support. From what I gather it was only recently added, but as it stands it’s not very useful at all. It can’t use categories in WordPress, and it also gives the wrong posting date. Oh dear. Here’s hoping it will be much improved before the final release.
Overall
I’ll be honest, I’ve never been as interested in any of Microsoft’s products as I am about Office 2007. Public betas, blogs such as Jensen Harris’s and a fresh interface really seem to have moved the product forward.
The Ribbon isn’t as obtrusive as it may look, and it can be collapsed to give even more space to the document. It didn’t really take any getting used to, and I have a feeling that once you’ve used it for a few days you won’t want to go back to the land of toolbars.
The biggest complaint I have is the lack of consistency in usability. The Ribbon makes using most features much, much easier, but it’s a shame that there are still poorly designed dialogs present.
I realise I haven’t dug too deep into the products, but for general use they’ve been a pleasure to use. Word is certainly a big improvement, and I don’t think I’ll be switching back to Office 2003 any time soon.
Related posts:
Completing a software project takes time and a whole heap of patience (amongst other things). There are plenty of ways to stop a project from reaching the finishing line, which can cause big problems for an indie developer. Not all of the problems outlined here will affect indies, but you’re bound to find something you can use to help your project die a horrible, drawn-out death.
Different Kinds of Failure
There are plenty of ways that a project can be considered a failure. Some are more subtle than others, and may depend on the kind of software being developed and the individuals involved. Common types of project failure are:
- Over budget – The project is finished, possibly before the deadline, but cost much more than expected. This may not be such a big problem for large companies, but for a small business with a tight budget, it can be disastrous.
- Late delivery – The project is finished, but this time it is later than initially promised. Again, this may not be a fatal problem for a big company. For some people though, it can be so bad that a day late is a day without food on the table.
- Lack of promised or essential features – If you promise your software will do something and it doesn’t, then that’s a pretty big problem. This type of failure may be a symptom of trying to avoid either (or both) of the problems above.
- It’s not what the client wanted – Similar to the above, although it’s more likely to be caused by bad specifications than by poor scheduling.
- It doesn’t sell – This is another type of failure that can kill an indie developer. Failure to sell can be the result of poor market research, a lack of marketing or a plain sucky product.
- It’s cancelled – This one is pretty obvious. A cancelled project can be a sign of any number of symptoms, from bad management to a lack of resources.
Now we know the types of failure, let’s see what we need to do to achieve them!
Before Work Starts
There are plenty of things you can do before the project starts to make sure that it never succeeds.
- Ignore client requests – If you’re working directly for a client, make sure you ignore what they ask for. After all, you’re the one who knows how to create software, right? You can score bonus points here by mocking them, pretending to listen whilst doodling, or blinding them with jargon.
- Create fuzzy requirements – If you must create a list of the user’s requirements, make sure they’re as generic as possible. Don’t bother detailing what features the finished product will need, because you might want to change it later. Also make sure to include as little detail as possible, and leave the requirements open to speculation. If someone has to ask for clarification on what a feature does more than once, you know you’ve done your job.
- Don’t put effort into design – Design is for hippies, so make sure you only vaguely describe a few bits of the software. Make sure to leave out details on the most important features, and definitely don’t describe how people will use the software. Include a few designs scribbled on a beer mat, so you look like you’re completely devoted to the project.
- Implement the least important features first – When the client sees you’ve gone to the effort of implementing some of the least important features, they’ll think you’ve gone the extra mile. Make sure you escape before they realise what you gave them is just a husk of a product. Bonus points for using a smoke bomb in your escape.
- Schedule your time poorly – We all know you’re such a cool programmer that you can write a 3D engine in a few days, and that the AI routines are a three hour job for you. Make sure the schedule reflects how awesome you are.
- Swap people around – If you have more than one developer, make sure they all work on something they’re least proficient at. After all, this will help them get better, so you’re actually doing a good thing!
- Don’t specify the level of quality you’re aiming for – Your product will totally rock, so don’t bother setting any quality goals.
During Implementation
- Don’t use source control – There’s no point in wasting a few hours setting up a source control system, because nothing bad will ever happen to your code.
- Don’t organize yourself – Once work has begun, don’t bother interrupting the flow by reviewing your project’s progress. Remember – Everything will be all right.
- Ignore ready made components – There’s a plethora of well written, fully tested components that can be integrated into your software. Using them will shave precious time off your schedule, and allow you to actually get the damn project out of the door. They’re your worst enemy, and you should treat them as such.
- Make everything more complicated – If there’s a choice between writing a small module that implements all the functionality you need, and writing a huge set of modules that uses all the latest design patterns you’ve been reading, you know which one you should choose. Bonus points are awarded for refactoring your code so that each method is only three lines long.
- Don’t track bugs – Keeping track of bugs makes it much easier to eliminate them, and that would mean you’d have to waste time fixing things instead of creating cool new code.
After Implementation
Don’t panic if your project has actually been completed on time and under budget. There are still plenty of ways you can make sure it never reaches its full potential.
- Don’t promote it – Your product is so good, it’ll sell itself! Don’t ignore the fact that marketing is one of the largest factors in a project’s success. Just make sure you do as little as possible. Try including a link in one of your forum signatures, and that should be enough.
- Don’t support it – Don’t respond to customer emails, and ignore any requests for help. Feel free to add a wiki to your website, and tell people that if they don’t know how to do something, they should add it themselves. Remember to be as rude as possible.
- Don’t improve it – Once your product is done, it’s done. Don’t waste time refining it, because we all know that good software is written in one go.
- Ignore feedback – If someone suggests an improvement, no matter how small, you should ignore it.
Remember
The real challenge with helping a project to fail is making it look like you tried your best to prevent it. Be as creative as possible when thinking of ways to help your project to its demise, and you’ll soon be celebrating a complete disaster.
Check out the developer articles section for articles on project management, marketing and business improvement.
Related posts:
As an Indie developer, you must wear a lot of “hats” in order to run your business properly. Perhaps the least favourite hat for developers is the “planning and scheduling” hat.
A lot of indie developers come from a programming background, including myself, so we should all know the benefits of planning; shorter development times, improved software quality and less hair pulling. However, there’s still a lot of friction and procrastination when it comes to planning.
A true story
We’ve all read the examples about how valuable planning is, but I’ll include my own to prove it. Let’s take two developers: Bob and George. They both come from a programming background, and they’re both working on a similar style of game. Bob knows the value of planning, and he writes a detailed plan of exactly how is game is going to turn out. George decides to “wing it”, and just scrawls a few screens and flowcharts. He’d much rather program, and whilst Bob is still “wasting his time” planning, George has a good head start. Stupid Bob!
Twelve months later, and Bob has finished his game well before his deadline. In fact, and it’s a top seller all over the world. He’s rather pleased that he “wasted” that time planning.
And what happened to George?
His game never got completed, because he overlooked several problems that Bob found in the planning stage, and it was too hard for him to fix. He doesn’t have a proper job now, but for $5 he’ll love you long time.
Ok, so I made that entire story up, but it illustrates an important point – planning is good.
So why do we hate it when it’s so valuable?
It’s not programming…
It sounds obvious, but planning is not programming, so there’s already some resistance. There’s often a one dimensional view of what’s involved with completing a game – it won’t get completed unless it’s programmed, so any activity that isn’t programming is seen as a waste of time.
Fear of making a mistake…
There’s often a feel that the plan needs to be absolutely perfect. Here’s the good news – it doesn’t. Plans can often change during the course of development, and this is perfectly normal (within reason – too many changes are a symptom of “feature creep”). It’s more important that the plan is kept updated, rather than remaining stagnant and outdated because nobody dares to change it.
It’s scary…
Writing a big plan is scary on two fronts.
First, we’ve often seen the huge, monolithic design documents that large software companies churn out. You know the ones I’m talking about – they’re the kind that weigh more than the entire development team. Indie design documents can be much more lightweight, as they don’t need to cover all the corporate red tape.
The second scary thing is confronting exactly what is going to be involved in creating the product. It forces you to look at the big picture, and accept the fact that creating a 3D engine in a weekend is just a pipe dream. It’s never easy to admit that you can’t do something, but planning and scheduling a project helps you to develop more realistic expectations and will save you a lot of pain in the long run.
It’s boring…
What’s more exciting? Writing a new whizz-bang particle system, and watching colourful sparks fly across the screen, or writing about it? Exactly.
It’s hard work…
Perhaps the biggest problem is that planning can be hard work. Thrashing out all the details of a project is difficult, and it makes you realise just how complex software construction is.
Thankfully, it gets easier with practice, but it’s still a pain to get a good plan completed.
So why bother?
One hour of planning can save anything up to ten hours of implementation work. I think that’s reason enough.
Related posts:
