Existe uma concepção geral entre muitos usuários e clientes comerciais de que, quando parece completo, está quase completo. Como você provavelmente sabe, isso está longe da verdade. Pode-se ter uma boa aparência, mas sem back-end e alguns usuários pensam que fazer com que pareça agradável é 80% do trabalho, não 20% ( ou os outros 80% ).
Inúmeros desenvolvedores podem contar histórias de horror sobre isso - obter uma maquete das páginas feitas no Microsoft Word usando capturas de tela de alguma outra ferramenta, e o cliente dizendo "então, você quase conseguiu?"
Você precisa acompanhá-lo para que todas as peças estejam prontas quando terminar. Tentar fazer todo o back-end primeiro e depois todo o front-end levará o usuário final a pensar que você não está fazendo nada e a perguntar por que você está sendo pago quando não há nada para mostrar. Por outro lado, primeiro o front end e você encontrará o usuário final fazendo alterações e consumindo o tempo todo.
O pior caso de um 'primeiro e o outro' é quando você chega à outra parte e descobre que ele não se encaixa no design.
Assim, construa ambos. Mostre o progresso no front-end, faça o back-end funcionar com o que você está construindo. Em muitos casos, é uma boa ideia fornecer compilações incrementais e garantir que você esteja fazendo o que o cliente deseja (isso entra no Agile). Se demorar demais com 'avanços visíveis' pode prejudicar o relacionamento com o cliente (isso ocorre nos dois casos de 'tudo parece ser feito cedo' e 'nada é feito até o fim' - é difícil para o cliente ver a estrutura sendo escrita ou testes de unidade ou higienização de dados conforme o progresso).
Joel escreveu sobre isso em O segredo do iceberg, revelado :
Corolário importante dois. Se você mostrar a um não programador uma tela com uma interface de usuário 100% bonita, eles acharão que o programa está quase pronto.
Pessoas que não são programadores estão apenas olhando para a tela e vendo alguns pixels. E se os pixels parecem formar um programa que faz alguma coisa, eles pensam "oh, Deus, quanto mais difícil seria para fazê-lo realmente funcionar?"
O grande risco aqui é que, se você zombar da interface do usuário primeiro, presumivelmente para que você possa ter algumas conversas com o cliente, todos pensam que você está quase terminando. E então, quando você passar o próximo ano trabalhando "escondido", por assim dizer, ninguém realmente verá o que você está fazendo e eles acharão que não é nada.
Isso é reiterado novamente na postagem do blog. Não faça a demonstração parecer concluída, com este gráfico útil:
Observe aqui que as duas opções geralmente refletem o 'faça a interface do usuário' (e a expectativa é que você faça isso em breve) e 'faça o back-end' (e então o cliente está preocupado com a falta do prazo).
A aparência de algo 'pronto' deve corresponder à aparência de algo 'pronto'.
Todo desenvolvedor de software já passou por isso muitas vezes em sua carreira. Mas as ferramentas de editoração eletrônica causam a mesma dor de cabeça para os escritores de tecnologia - se você mostrar a alguém um rascunho que está perfeitamente tipificado e formatado, eles o veem como mais feito do que você gostaria. Precisamos de uma correspondência entre onde estamos e onde os outros percebem que estamos.
Este artigo também traz um ponto importante sobre o tipo de feedback que você recebe com diferentes níveis de integração da interface do usuário. Se você tem algo que parece completo, é mais provável que obtenha feedback sobre "você pode alterar a fonte" do que "esse layout não funciona - há muitas guias".
Para aqueles que estão lutando com isso no mundo do Java Swing, há uma aparência chamada Napkin que faz com que a interface do usuário não pareça completa (mesmo que seja).
A chave aqui é torná-lo para que não pareça pronto. Ter a interface do usuário concluída é um sinal para muitos usuários de negócios de que o aplicativo está completo (mesmo que sejam apenas algumas páginas estáticas sem lógica por trás dele ou algo construído em um construtor de interface).
Leitura adicional (e links do artigo):