Posts Tagged: enterprise software

Main — Comments Off
22
Sep 09

Documentation

Jim Highsmith wrote: “Documentation is often the solution to a communications problem that can’t be corrected with documentation.”

I found this to be a good reminder. I mean, the point of documentation is a simple one isn’t it? To convey ideas and intent clearly and without ambiguity. We write it down because we can’t remember long enough or clearly enough, or we don’t trust the people we are working with enough. (“I asked for X” “I thought you asked for Y” “well, let’s go look at the document!”)

If we worked in smaller iterations (with people we trust), our need for documentation would decrease exponentially. With contract thinking (ie, everything must be written down and signed) increases project cost by 30-50%. That’s a lot of waste for a problem that is pretty easy to solve.

I suppose there is a secondary purpose to documentation that focuses on tracking the history of an item. But let’s be honest – how many times do you go back and look at project documentation after it has been released into production? In my experience, the more detailed the document, the faster it becomes irrelevant and unhelpful.

Picture 1

Main — Comments Off
15
Jun 09

Ignore Sunk Costs

Seth writes:

“When making a choice between two options, only consider what’s going to happen in the future, not which investments you’ve made in the past. The past investments are over, lost, gone forever. They are irrelevant to the future.”

I agree. Too many bad things happen when people insist on preserving the past only because they paid a lot for it. It might be painful, but sometimes you have to true up and say: That might have been a good decision when it was first made, but it is not a good decision today. Be honest with yourself, and embrace the change.

Main — 1 Comment
2
Apr 09

Buy and Configure vs. Build on a Framework

So the trend seems to be favoring purchasing software over building it. But I think Buy vs. Build is a slippery slope, and more so, should be more clearly named: Buy and Configure vs. Build on a Framework.

In my mind, the difficulty of configuring down a complex piece of software is really just  as difficult as building up a piece of software from pre-built frameworks, plug-ins, and templates.

The intent with Buy is not necessarily to spend money (though I do know people that value software strictly on its price tag), but to follow a basic principle: don’t reinvent the wheel. If someone has already done it,  use that first. The question for me is: when does configuration cost more than building?

Buy or Build Where you spend your time Considerations
Buy the enterprise tool that does everything comparing and contrasting various products, learning how to use the proprietary product you select, and a lot of configuring does more than you want, pay a company for support
Build with pre-built frameworks, plug-ins, and templates understanding your business need, learning how to use general-purpose components, and program what you want does exactly what you want, pay a consultant for support

In my experience, configuring is very expensive. I think about my Java programming days when it felt like half of my time was simply spent figuring out how to configure the fancy and expensive server.

From a learning perspective, I’m all about the build. I would much rather have knowledge about a general-purpose framework than knowledge about a proprietary system. General-purpose knowledge has much longer-term value, and can be re-used over and over and over again.

What do you think?

Main — Comments Off
9
Mar 09

Enterprise Apps

Michael Nygard contemplates Why Do Enterprise Applications Suck?

I mean, have you ever seen someone write 1,500 words about how much they love their corporate expense reporting system? Or spend their free time mashing up the job posting system together with Google maps? Of course not. But why not?

Read more to find out what he thinks.

Main — Comments Off
25
Jan 09

Usability with Agile

Usability expert, Jakob Nielsen conducted some research about Agile Development Projects and Usability:

For 50 years, almost all experiences have shown that traditional waterfall development methods result in a poor user experience. The reason is simple: requirement specifications are always wrong.

Jakob says successfully integrating usability into an Agile approach involves 3 basic strategies: 

  • “Perform usability activities, such as user testing, in a few days.”
  • adopt “a parallel track approach, where the user experience work is continuously done one step ahead of the implementation work”
  • build “foundational user research that goes beyond feature development”

[Thanks for the bookmark Striving Green!]

← Older Entries