Archive : December 2007

2007 in review: Five humble suggestions for better programming and writing

Brian Dillard, Monday, December 31, 2007 @ 1:33 pm

I began 2007 as a front-end tech lead on a multi-million-dollar software project for a global travel company with a massively distributed waterfall development model. I ended it working in small, agile teams on R&D projects at a small outsourced software shop. I got involved in open source, became (yet another) tech blogger, and set in motion lots of other writing and speaking projects for 2008. It's been quite a year.

I'm sure everybody is sick of year-end lists at this point, so let me present a slightly more personal and highly subjective list of the five most important things I learned this year about software development and technology writing:

Continue reading »

Topics: , , ,

Software Development Software Development

Another Brain Fart on Why Open Source is Bad

Dietrich Kappe, Monday, December 31, 2007 @ 12:32 pm

Every so often, someone scrawls a manifesto about why closed source is good and open source is bad. Usually the parties involved are technical ignoramuses (like in this Economist article) or industry hatchet men. But Jaron Lanier should know better. He isn't a hatchet man and is far from a technical ignoramus, yet he engages in the same sort of sloppy thinking that characterizes those other brain-stain graffiti artists.

His article for Discover Magazine, entitled Long Live Closed-Source Software!, is a case study in bad examples in the service of a simple argument. His argument goes as follows:

  1. Open Source == Linux
  2. Linux is a derivative if qualitatively better version of the closed-source UNIX.
  3. Therefore the open source movement can only produce derivative works, and nothing as breathtakingly revolutionary as the iPhone.

He goes on to speculate about some of the causes for this failing, likening closed source to cell walls that help organisms differentiate and speciate. Open source, by contrast, is like the primordial goo.

Continue reading »

Topics: ,

Software Development Software Development

RSpec and Rails Custom Form Builders

Noel Rappin, Friday, December 28, 2007 @ 4:27 pm

I'm working on a small project and trying to use RSpec as the complete testing solution. First thing I did was copy over an existing custom FormBuilder which puts everything in a nice tabular layout. Then I tried to convert the existing Test::Unit tests to RSpec specifications.

I banged my head against this for a few hours, at least partly because the normally-infallable Google-based tech support failed to expose a clear example. So I figure I should at least get a blog post out of it.

The form builder is technically a helper, so it goes in app/helpers, and the test goes in spec/helpers. One problem -- the custom form builder expects to have access to template object and calls content_tag on that object to format the output. Normally, the template object is automatically placed in @template during evaluation. But since RSpec is testing just the helper, and not an associated controller or view, there is no template object.

At first I created a mock template object that just imported the relevant Rails helpers, but then I actually read the documentation in more detail and learned that the RSpec HelperExampleGroup class, which manages helper tests, already imports all those helper modules. So, I can set up my specs like this.

before(:each) do
@object = mock_model(Project)
@object.stub!(:longname).and_return("Long Name")
@builder = TabularFormBuilder.new(:project, @object, self, {}, nil)
end

The first two lines of this just set up a mock object. The key line here is the last one, where the form builder is created with arguments representing the model, the instance, the template, and then options. The template is represented by self, meaning the RSpec HelperExampleGroup, which will respond to content_tag.

Now I was able to write all my specs against the template and use the have_tag and with_tag predicates to validate the output, like so:

it "should build input fields" do
@builder.text_field(:longname).should have_tag("tr") do
with_tag "td.tdheader"
with_tag "label[for *= project_longname]", "Longname"
with_tag "td" do
with_tag "input.text_field#project_longname[name *= longname][size = '30'][value = 'Long Name']"
end
end
end

One other nice feature of the helper specs in RSpec is the ability to directly evaluate ERB. This is designed to be used for validating helpers that take ERB blocks as arguments. Use as follows:

eval_erb("<% table_form_for (@object) { |f| f.text_field(:shortname) } %>")

The method being tested looks like this -- it wraps a form inside an HTML table so that the custom form builder's table layout will render properly:

def table_form_for(name, *args, &proc)
concat("<table>", proc.binding)
form_for(name, *convert_args(TabularFormBuilder, args), &proc)
concat("</table>", proc.binding)
end

The eval_erb method returns a string, which you can then validate. Note that if you are using it to test a form_for derivative like this, you also need to place the following stub method in your spec file's describe block:

def polymorphic_path(args)
"http://a.fake.url"
end

The polymorphic_path method is used within Rails to convert something like form_for(@object) to the RESTful URL that the form should be submitted to. Normally it's an method of the controller, but in the RSpec helper environment, there is no controller.

There's another issue when validating this form builder. Unlike a typical ERB block, the custom form builder implementation of f.text_field explicitly uses the template object to write output. The eval_erb method does not seem to work as I expected in this case -- the output from inside the block does not appear to be saved.

In other words, when running the eval_erb call above, the resulting string contains the table tag created by the table_form_for method, and the form tag created by form_for. The table rows that are built by the custom form builder itself, however, do not show up in the output. I was able to verify that the output is being generated, so either it's not being stored by the RSpec object, or I still haven't completely figure out how to tie these things together yet.

If you found this example helpful, you might also enjoy my upcoming book Professional Ruby on Rails, scheduled to be published in February, 2008.

Topics: , ,

Software Development Software Development

Dead Duck Typing and High Cohesion

Dietrich Kappe, Friday, December 28, 2007 @ 3:18 pm

I'm sure you're familiar with Duck Typing, in particular as espoused in the Ruby world: "If it walks like a duck and quacks like a duck, I would call it a duck." Nothing is an unmitigated good, but Duck Typing, or designing against interfaces, is generally a good thing. It allows you to abstract away the implementation details, which is a very good thing in the OO world. One thing missing from Ruby, however, is Dead Duck Typing, i.e. when you cook the duck in the oven, you probably don't want it walking and quacking.

Why wouldn't you just have a different class or object, a "Roast" object that you construct when you kill a duck? Well, you might want to do that, sort of like a "Duck Transfer Object," or DTO. But in some cases, creating a separate object, just so it can be used in a different context, adds unnecessary complexity to a system. Take the example of an accessor in Ruby. I may need to give some other Class the information on how long to cook the duck and at what temperature, but do I need to give that to the pillow manufacturer who is only interested in the feathers?

Paddling away from ducks for a moment, think of the typical business and persistence layers in an application. In the persistence layer, the implementation details need to be exposed, in the business layer, they really shouldn't. In Ruby, you can't hide methods in different contexts, so you end up with cluttered interfaces -- monsters instead of ducks -- that rely on good programmer behavior to prevent tight coupling and low cohesion from creeping in (see the GRASP patterns). Instead, we want High Cohesion, i.e. all of the methods of a Class should focus on one or at most a few responsibilities.

Some will argue this is a Java-ism creeping into Ruby. I say this is just plain old-fashioned good OO design.

Technorati Tags: , , ,

Topics: , ,

Software Development Software Development

2008: The Year In Advance…

Noel Rappin, Friday, December 28, 2007 @ 12:16 pm

Oh, we're doing predictions. Sure:

  1. The blurring between desktop and web applications will continue. Especially watch for desktop applications specifically designed to enhance one specific web site (like the Mac applications Twitterrific and Mailplane). There are at least two other efforts to allow you to easily bundle an arbitrary web site into something that acts like a desktop app. I agree that Google Gears-like functionality has a strong place here.

  2. On a related note, I'm kind of taken with the new Remember the Milk Firefox plugin, which adds GMail integration. It's a plugin that assumes a specfic browser and ties together two web apps. Using the browser as the clearinghouse for tying together disparate web data feels like something I expect to see more of.

  3. GWT will make some headway in porting existing Java apps to the web, but much of this will be on internal networks, so it will kind of slide under the radar. I don't see it picking up vast numbers of new developers who aren't already committed to a Java/Swing structure.

  4. One of the zillion or two desktop app suites will go under, prompting some panic for people who have stored documents there.

  5. For the Rails community, I expect the big issue for 2008 will be dealing with success and growth (RailsConf 2008 has more proposals for speakers than RailsConf 2006 had participants...). The tension is along the axis of developer efficiency vs. enterprise-y performance. Look for more attention to fall on smaller, more specialized Ruby frameworks like Merb.

  6. On a more technical level, I expect (or maybe more accurately, hope) that there will be some attention paid to improving the Rails view layer. Possibly a consensus on some kind of Presenter or Decorator pattern.

  7. My book, Professional Ruby on Rails, will be released. You will buy a copy. (Hey, I can hope...)

Topics: ,

Software Development Software Development

Markdown support for GWT in 42 seconds

Ivan Moscoso, Friday, December 28, 2007 @ 10:42 am

As promised earlier, here is Markdown support in GWT.

1) Grab Showdown
2) Copy 'showdown.js' to the 'public' directory of your application.
3) Edit your module file: 

    <module>        <!-- .... -->        <script src="showdown.js"/>        <!-- .... -->    </module>

4) Use JSNI to invoke Showdown.

    public static native String convert(String text) /*-{        var converter = new $wnd.Showdown.converter();        return converter.makeHtml(text);    }-*/;

5) Invoke 'convert()' as needed.  In my case, I wired it up to a KeyboardListener attached to a TextArea, and had the results placed on an HTML object.

And yes, it's that simple.

Topics:

Software Development Software Development

Markdown, GWT & Regular Expressions in Groovy

Ivan Moscoso, Friday, December 28, 2007 @ 8:41 am

If you haven't been able to tell yet, I like Groovy.

I was playing around with enabling some Markdown support in GWT (attempting to use Markdown-J from inside a TextArea instance widget).  Because Markdown-J relies on java.util.regex classes, it can not be invoked directly by GWT. I decided to take two approaches-- the first being to invoke the Markdown-J processor via an RPC call, and secondly to do it all on the client-side (which I will address later).

The first approach meant I could do some interesting things along the way in Groovy.  First off, I wanted to extend the Markdown processor to support table markup similar to, say, a FitNesse test (i.e turning markup like this):

|com.some.fixture.DummyTestFixturePlusOne|| input | expectedOutput? || 10    | 11              || 44    | 45              |

Into HTML output like this..

com.some.fixture.DummyTestFixturePlusOne
input expectedOutput?
10 11
44 45

Or other alternate (possibly interactive) representations of tabular data using GWT, if you get my drift (but that's another show).

The implementation of Markdown-J is relatively straightforward.  It makes heavy use of regular expressions (java.util.regex can not be referenced by GWT), and thereby serves as a good illustration of the paradox of regular expression support in Java:  You can get the job done, but it's rarely nice to look at.  Groovy makes it so much better.  Here's my first attempt to extend Markdown-J's "MarkdownProcessor" class from a Groovy class.  Nothing special up my sleeve here.

class MarkdownProcessorWithTableSupport extends MarkdownProcessor {
    private static final tableRegex = /\|([\d \w\.]+)\|[\n\r](.*\|)(?:[\n\r]?[^\|])/

    public TextEditor runBlockGamut(TextEditor text) {
        TextEditor editor = super.runBlockGamut(text)
        String content = editor.toString()

        content.eachMatch (tableRegex) { match ->
            String headerRow = match[1]
            String tableContent = match[2]
            // do something with this match..
        }
        return new TextEditor(content)
    }
}

This is enough code to extract the first two match groups in the regex and start doing something with them.  The only real item of value in this class is the regular expression.  That regex took me a bit of time to nail down, so obviously it's rewarding to have it represented as closely as possible without any of the double-backslash marks you find with Java strings.  Notice that Groovy avoids the '\\' hell when describing regular expressions with it's "slashy" style strings.  'tableRegex' is still a String, you see.  But unlike the double-quote delimiter, the '/' delimiter allows things like unescaped backslashes.

Other than the regex, everything else in the code is rather boilerplate (iterate over each match, generate some HTML markup, yadda yadda... you get the idea).  Take note of the 'eachMatch' invocation on my String content though.  There's more going on than you might imagine-- Groovy actually takes the regular expression and compiles it down to a java.util.regex.Pattern instance before evaluating the closure.  Isn't that nice?  After all, it's what I would have done in Java anyway.

What's next?  I think it makes sense to try something like Showdown and bake it into a GWT component.  This will be my first attempt to integrate some existing JS library and see how nicely it will play with GWT.  Stay tuned.

Topics: , ,

Software Development Software Development

Blue Christmas

Michael Dain, Thursday, December 27, 2007 @ 3:38 pm

I took time out this Christmas season to reformat my hard drive. Yes, it seems pitiful when you work with these machines all day, and have a chance to spend quality time with loved ones how machine maintenance would top the list of things to do. However, it did give me a chance to mull over a bit of design mystery which seemed a decent enough present to share with you all. Cozy up to the fire and let me tell thee about Windows Vista.
vista menubar Being a Mac user, I do have a generally favorable impression of the Redmond efforts, I have a healthy background in their CMS system Sharepoint, and felt as long as you keep up to date on their latest and greatest (read beta) releases, you can almost forgive them for not being more mac-like. So armed with my copy of parallels, I installed versions of XP and Vista, and when my hard drive went belly up I decided to keep just the Vista version. Vista has a great deal of interesting abilities. I am a big fan of the voice dictation software/interface. In a quiet room, it is almost faster than typing. I think the paradigm of the 'explorer bar' is pretty well conceived mashup of a breadcrumb menu plus drop-downs. I'm surprised not to see a web version of this, since it really does have a fairly good affordance to the user of traversing a deep directory structure.

vista is blueWhat really bothers me about the switch is the overall 'blueness' of the interface. It's relentless, and of course being good web 2.0 citizens, they got their gradient on, so its basically blue gradients for miles. Now, giving them credit, aqua (mac os x's first scheme) had the same problem, blue gradients for days, and the extraneous grey pinstripe thing, but yet it didn't seem as gratuitous as Vista. This is coupled with the inability to 'go grey' as XP used to allow. So, by redecorating, vista has 'painted' itself into a corner, unless users are expected to select their own gradient mixes (yellow to orange, puce to purple) they are somewhat stuck with blue. Also knowing microsoft, these are just bitmaps, so no redecorating is possible without replacing a bunch of .BMP's someplace deep in the WIN32 folder.

At the same time, Apple's Leopard has removed all hints of ever styling the chrome of their windows, even the pinstripe thing is removed and has gone all grey. They have also been having some fun with drop shadows (the 'other' gradient), in early beta's, and in Steve's intro speech, they spoke of how active windows really stand out. That was because active windows had about 100 pixels of drop shadow built in - which they wisely dumped. Overall, no color seems the best choice, in a black text on grey world, it tends to de-emphasize things well enough to let the user focus on the content at hand, photos, and clickable things (hopefully blue).

vista menubarSo, overall, why blue? If we look to web design, its pretty much the default color. It is hard to find a site that does not use blue as a background or decorative accent. Of course it is the 'real' clickable link color, and it is the color of azure sky in deepest summer, which is not a bad thing at all. In fact, since red is out, and yellow is kind of tricky, you pretty much have blue as your only possible primary color choice. However, color wheel not withstanding, it is hard to understand why blue has so much power over our virtual lives. About.com claims it's the color most preferred by men. It is also peaceful, tranquil, and productive. It is the least appetizing color- perhaps why foodtv chose green?

Perhaps web 2.0 has brought a reaction to this overall blueness, noting ebay has gone with yellow, but there will still be a strong reason to pick blue, it's like choosing IBM (pun intended) or the reason Microsoft is still the best choice for many reasons, nobody got fired choosing blue. Every other color has strong emotions tied to it, and neutrality (read grey) while being most suited to 'new' web design tends not to excite people too much. I actually have a difficult time finding a site where blue is not the predominant non-meaningful color. So, while I'm scouring google scholar for some actual research statistics on this phenomenon, please leave your comments on what interfaces sucessfully break this blue flu, and have a happy 2008!

Topics:

User Experience Design User Experience Design

Ajax Predictions for 2008

Dietrich Kappe, Thursday, December 27, 2007 @ 9:54 am

I'm a little early this year for my 2008 predictions. No matter. I seem to have been a bit early with my 2007 predictions as well, and as they say in the venture capital biz, "too early is the same thing as wrong." Some of my predictions did come true -- Ajax is no longer such a big buzzword; a number of framework specific books (GWT, jQuery) have been published at the end of 2007; Microsoft's Ajax stack continues to limp behind the rest. A few others did not, notably the ho-hum release of IE7 and the delay in FF3. So, let me try my hand at some more prognostication:

  1. Elegant, good looking frameworks like Ext and myGWT will gain traction. The more out-of-the-box good looks you can give them with CSS and bundle images and icons, the more acceptance they will gain.
  2. The JavaScript framework chaos will continue. The OpenAjax alliance will continue to be ineffectual in promoting things like widget interchangeability.
  3. Security will become a big headache, as less sophisticated developers start to venture into the wonderful world of Ajax, littering the web with state and control logic on the client side.
  4. Towards the end of 2008, FF4 and IE8 will start to change the landscape of Ajax and Web 2.0 with an update of JavaScript and new browser features.
  5. MS Volta will do nothing. It is just a FUD shot across the bow of GWT.
  6. Everyone except Craig's List will have some form of Ajax on their site.
  7. Desktop RIA's through Google Gears, Adobe AIR, etc., will start to make an impact in the second half of 2008. Look for desktop/web hybrids of the office productivity tools, such as word processors and Powerpoint clones, to see greater use in the corporate IT space.
  8. GWT's compiler will produce more efficient code than 98% of JavaScript developers can do by hand.
  9. With the new browsers, a cross platform Canvas/SVG will be a reality by the end of the year.
  10. IE8 will still leak memory like a sieve.

Have any of your own predictions? Feel free to add them in the comments.

Technorati Tags: ,

Topics: , , ,

Software Development Software Development

Viewport width: Size matters, but not in the way you’d expect

Brian Dillard, Wednesday, December 26, 2007 @ 5:51 pm

When a company gears up to redesign its website, the question of screen resolution always seems to eat up tons of time and energy. Despite the long, slow evolution of the browser from a publishing medium to an application platform, many developers still think in terms of "web pages" - large units that require, if not fixed dimensions, then at least a fairly defined range of viewport mins and maxes. Rather than thinking of the browser window as an operating system full of work spaces, palettes and menus, we think of it in print terms, like a newspaper page full of columns and sidebars. This occurs despite a decade of education to the contrary from any number of software and visual design experts.

Continue reading »

Topics: , ,

Software Development Software Development

Ajax Intervention: Safari Books Online (Bah! Humbug!)

Brian Dillard, Wednesday, December 26, 2007 @ 5:50 pm

Welcome to Ajax Intervention, in which we dissect how major websites misuse, or fail to use, Ajax to improve their user experience.

Up this time: Safari Books Online, a great programming resource that's hampered by poor usability and underbaked Ajax navigation.

Safari Books Online makes perfect financial sense for developers, their bosses, and top-tier tech publisher O'Reilly itself. For a modest per-seat subscription fee, developers and the companies they work for get access to a vast library of programming resources that never becomes outdated. O'Reilly and its partners, meanwhile, get a predictable revenue stream with practically zero incremental delivery cost. Everybody wins ... except for users who expect an interface that makes online books as intuitive as physical ones.

Continue reading »

Topics: ,

Software Development Software Development

IA and agility

Brian Dillard, Monday, December 24, 2007 @ 5:30 am

A friend of mine recently left a position at a supposedly Agile shop where developers wrote code based on raw requirements rather than formal IA. When he described their process to me, I really felt his pain. I can't imagine trying to capture the complex requirements of Ajax applications without the tools of modern IA.

Good information architecture provides not only detailed blueprints for developers, but also the raw material for test cases. If your only documentation of a component is just a high-level business document or a working example of that component, then it's difficult to identify deviations from the spec or prove that an unexpected behavior is a bug. Sure, on Agile projects the first-round IA sometimes gets reverse-engineered from working demo code. But IA and UxD should be a central component of Agile development.

Technorati Tags

Topics: , ,

Software Development Software Development

Agilize Your Project Just Before the First Release- for Fun and Profit!

Scot Witt, Friday, December 21, 2007 @ 5:35 pm

You're a full year into a multi-year multi=million dollar  project but the first actual release is seen o the horizon.

What does everyone do naturally?

PANIC, of course.

This time there was reason:

  • Your deliverables have been fine to date and the architecture is rock solid (just as you promised)

  • The Business Team is killing the Client Sponsor because the business team has exceedingly high expectations that should have been managed better.

  • Your Client Sponsor is getting angrier and angrier because his reports people can't do parallel testing on the old and new versions yet because your application still has issues. He originally planned for six months of such testing and might get two weeks under the existing schedule.

  • Your Client Sponsor's boss is demanding more functionality than your team can provide in a month of Sundays as it prepares for the first beta release and code freeze.

  • Your DevTeam is pointing fingers at you and the PM because they suspect (rightly) the client will want features build through load and performance testing.

Well, what could have been a major disaster with a lot of egg running off a lot of people was avoided with a lot of team assistance and a lot of hard work. No wonder I like working on teams so much:

1. Analyze the Problem and Causes

We're in the first code freeze of my first Agile Project. It took a lot of doing.

The problem was:

  1. Exceedingly poor communication
  2. Lack of planning
  3. Lack of managing expectations (on both sides)
  4. Not using a more Agile approach sooner in the project than we did.

2. Experience Counts- Listen to It

Here's what our CTO (Chief Technical Officer) hammered into our heads:

  • Practical Agile Methods
  • The BA promotes communication between the Business and Technical Teams and acts as a day-to-day Project Manager for the Technical Team (high level- Technical Lead runs the team).
  • BA needs to meet and talk with the Client at least once a day (preferably with the IA (Information Architect).
  • BA runs the requirements gathering, documentation (just enough documentation), the non-SCRUM Meetings and handles the project calendar for the PM.
  • The IA is the interface and usability Czar/Czarina.
  • The Client controls the features/bug lists. But the feature/fix doesn't get on the list until the BA/IA translates the into documents the Developer can develop from.

Our PM is also the firm's Sales Director. He revised his role to be umbers cruncher/support for the BA/IA and Lead Developer instead of intermediary between the customer and DevTeam/BA/IA. Instead, the PM and the BA will buffer the Client together.

3. Take Concrete, Understandable Steps

Here's what I (the BA- Deputy Associate Assistant Project Manager In Waiting):

Defined terms for both sides in their own contexts. I originally started a Glossary of terms, but someone from UxD pulled it. It was never used, never updated ad never referred to. Never again.

  • The business side didn't know a checkbox from a checkbook.
  • The DevTeam had no idea what 'parallel testing' meant nor how deep it went (down to the field level for hundreds of transactions).

It got worse, then got a little better when we formalized the process and touch points. Now every feel confident in asking "what does that mean?" Oh, how my first radio news director would smile!

Explained, demonstrated and awarded control of the Agile-based process to the business team four or five times and adjusted it to make them feel comfortable in their Word, PowerPoint and Excel World.

I gave up on the business side using any of the new tools except the bug tracker. The wiki is an active tool for the DevTeam and a simple resource for the Business Side.

If they're more comfortable in Office, fine, the BA and IA will translate i the wiki.

Told the DevTeam categorically it had but two 'controls' on the process- agreeing/disagreeing to a list of iteration features/issue repairs and providing the Client options and potential results/mitigation strategies.

A Developer can ask why a feature is needed/wanted, but the developer can't say no to a feature. If there's violet disagreement, offer options, but when the client makes an informed decision, that's it.

Got both sides into two actual Iteration Planning Meetings to get an identified list of develop-able items together for the upcoming iteration. What a concept! Things began settling down with the first freeze/performance-load test iteration plan and eased significantly with the list for the first 'go live' release that follows immediately.

Despite my best efforts, the DevTeam wasted the two days I set aside for research and questions between the first and second planned iterations with little stuff like speeding up the transaction times on the servers.

Got the Client to think out loud. ow we have the rudiments of a road map. Another planning tool!

Early Results:

The respect meter is consistently rising on both the Business and the DevTeam sides since we moved to a more standard.

Now don't get me wrong.

When we started, only our highly experienced Architect was Agile proficient and he was moving us to this sort of practice. We needed a lot more leeway to get the base functions designed, win client support and rapport as well as train the team. But as usual, communication is always the first casualty in any engagement we needed planning and giving the features over to the Client badly. Hence the major change a bit earlier than expected.

Things are a lot calmer, the client is more satisfied now that he knows where items he wants may be developed (we're Agile- these plans and iteration lists are like vaporware- useful only to make everyone realize that any change means a push for the item originally planned for.)

I'll letcha know what happens as we continue down this path, but it looks really good and will allow us to get automated testing implemented along with regression ad unit testing fairly easily from my perspective...making us test-based developers a lot sooner than I thought.

Powered by ScribeFire.

Technologies and Platforms Technologies and Platforms

Ajax and Browsers: Recapitulating the Early Days of Personal Computers

Dietrich Kappe, Friday, December 21, 2007 @ 10:20 am

I guess its my turn to spin out historical analogies. Does anyone remember GEOS? That's right, a GUI OS for the Commodore 64. In those early days, everyone rolled their own GUI  (character mode windowing...yum). Some were good, some were bad, some were downright ugly. GEOS was an attempt to bring the unifying influence of an OS that provided the basics of a GUI to the C64, something that Windows brought to the PC and the Mac OS brought from the beginning to the Macintosh. GEOS and the C64 faded away, but the days of the custom crafted GUI were numbered. All that stuff is and should be baked into the OS.

We're in a very similar situation when it comes to the browser and Ajax/Widget libraries and frameworks. Everyone is rolling their own widgets, developing their own DOM and Ajax utility libraries and frameworks. I think the next step should be obvious. Bake an Ajax library into the browser. Can you imagine having Ext already present and available in your JavaScript runtime? Imagine the boon this would be to standardization, code reuse, etc.?

Continue reading »

Topics: , , , ,

Software Development Software Development

The Confluence of UXD and Agile

Dietrich Kappe, Thursday, December 20, 2007 @ 11:18 am

User experience design is integrated into software development and other forms of application development in order to inform feature requirements and interaction plans based upon the user's goals. The benefits associated to integrating these design principles include:

  • Reducing excessive features which miss the needs of the user
  • Improving the overall usability of the system
  • Expediting design and development through detailed and properly conceived guidelines
  • Incorporating business and marketing goals while catering to the user

--Wikipedia

Consultants lie. They tell you that software X can be developed in time Y for cost Z. That is a lie, plain and simple. The consultant has developed software before, and you know your business, but the two of you have never developed this particular piece of software before, otherwise you would be using it now instead of developing it. So, by definition, in software development you are doing something for the first time, otherwise you would be performing system integration.

This may explain why study after study finds that Software Engineering is notoriously poor at estimating, and why software projects typically run over in terms of cost and time. Enter Agile. Agile doesn't so much eliminate risk as admit that it is there. You don't bother putting together a 24 month project plan because you realize that:

  1. The estimate will be off my 400% or more.
  2. The client thinks they know what they want, but really doesn't.
  3. You'll know way more and make better estimates after 3 months of working on the project.

Continue reading »

Topics: , , ,

Software Development Software Development

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Categories

Topics

Blogroll

Search

WordPress

Comments about this site: info@pathf.com