[freudling]

So we're knee deep in software development. Things are going fairly well. However, I find that our Chief Engineer is pushy. He pushes to prototype architecture and involve our interface designer, who should have been wireframing weeks ago. Now the developers keep asking for wireframes and we're behind. Interface design to me is so important and incredibly challenging.

I also find that wireframing is a dependency for user stories. You can sit around and try and think up user stories but the output of wireframing is user stories. And user stories can change based on changing interfaces.

Then we have one Engineer who wants to follow agile PM to a T where reality and other people dictate otherwise.

Finally, the Chief Engineer thinks that people working anymore than 40 hours a week are wasting time because their productivity will suffer. However, I work 12 hours per day. We're a tech start up.

Any comments, suggestions, or advice?

[The Godfather]

Hire an extra interface designer.
Show the timesheets to drive your point.

[besson3c]

Work with low fidelity prototypes such as simple drawings. High fidelity prototypes are great, but they take too long to produce, and it is tempting to waste time on making them look good rather than simply convey meaning.

[freudling]

Both good advice. Keep it comin'.

[BLAZE_MkIV]

Wait, you have an interface designer and ui mockups? Your so lucky. I'm staring at 350k of code thats been hacked at for the last 5 years since the original coder got tired of dealing with Tcl, whipped this thing up in a few weeks.

So my advice, make no assumptions during you're design. Expect everything to change.

[besson3c]

It sounds like there is some struggle separating design issues from UI issues.

By design issues I mean fundamental questions like:

- what is the scope of this application?
- what are the milestones, designed to prevent scope creep?
- how do we deal with user that wants to do A or B or C?
- to what extent do we abstract the code to allow for changing design parameters and therefore allow for future growth?

I would say that the UI needs to reflect all of this business rationale, and if you are consuming too much time with UI it's probably not because of high standards, but because this business rationale is fuzzy. Yes, it is certainly possible to have razor sharp business rationale and debate over the best UI, but I would say that more often than not the problems are the above.

The above is also why most small businesses fail. I would say, unless you can say with complete confidence that the above is not an issue (which would be surprising to me), don't bring UI discussion into the picture just yet, focus on these issues, and don't neglect them. Bring UI into the picture only when the above is on firm ground.

[freudling]

Originally Posted by besson3c 

It sounds like there is some struggle separating design issues from UI issues.

By design issues I mean fundamental questions like:

- what is the scope of this application?

It's clearly defined.

Originally Posted by besson3c 

- what are the milestones, designed to prevent scope creep?

Clearly defined.

Originally Posted by besson3c 

- how do we deal with user that wants to do A or B or C?

Many late nights.

Originally Posted by besson3c 

- to what extent do we abstract the code to allow for changing design parameters and therefore allow for future growth?

By hiring good engineers who understand that producing code that is scalable, flexible, and robust is a must and just part of life.

Originally Posted by besson3c 

ItI would say that the UI needs to reflect all of this business rationale, and if you are consuming too much time with UI it's probably not because of high standards, but because this business rationale is fuzzy. Yes, it is certainly possible to have razor sharp business rationale and debate over the best UI, but I would say that more often than not the problems are the above.

The above is also why most small businesses fail. I would say, unless you can say with complete confidence that the above is not an issue (which would be surprising to me), don't bring UI discussion into the picture just yet, focus on these issues, and don't neglect them. Bring UI into the picture only when the above is on firm ground.

I'm sort of getting lost in your answer at this point. What I'm finding, particularly today, is that UI design is more important than ever. There's too much software out there now... Too much choice. If you don't have a super clean, killer interface design then it's much harder to compete.

That the design of the interface is a massive part of how your software will work, what people will actually see, and what features this "pictures under glass" tool has.

Engineers suck at UI design, and good UI design is really really hard. Downplaying it is a recipe for failure.

Like Jobs said, "Design is how something works." It completely defines it.

Yes... There's architecture design, but nobody "sees" that and nobody cares. We all expect our engineers to build within the confines of the design of the product.

I'm interested to see what you've done? Any software titles you can point out? Maybe I can glean some good info from your examples to help us.

Thanks.

[besson3c]

I don't understand why you feel put on the defensive freudling?

If your project has a good business focus, awesome, I don't doubt that, I was simply pointing out that this is often rare.

If you have that focus, by no means am I discounting the importance of UI, I was just making the point that this UI needs to be mulled over after the project has been well designed and conceived of. Otherwise, you'd be trying to nail down a moving target.

[freudling]

Originally Posted by besson3c 

I don't understand why you feel put on the defensive freudling?

If your project has a good business focus, awesome, I don't doubt that, I was simply pointing out that this is often rare.

If you have that focus, by no means am I discounting the importance of UI, I was just making the point that this UI needs to be mulled over after the project has been well designed and conceived of. Otherwise, you'd be trying to nail down a moving target.

I'm not on the defensive. I just want to learn. Do you have any titles out there? I'd like to see the process behind success. All of it counts and is helpful.

[besson3c]

Originally Posted by freudling 

I'm not on the defensive. I just want to learn. Do you have any titles out there? I'd like to see the process behind success. All of it counts and is helpful.

It sounds like you are attacking me, questioning my eligibility in offering the advice I'm offering. I hope this was not your intent, I'll assume it wasn't.

I'm a web developer, so I don't know if the projects I've been involved with would be pertinent to you. I've developed several web applications, several of them unfortunately private and requiring a login (including two homegrown CMSes), a game, a whole bunch of little open source web based widgets, and several websites including this one we actually just launched this weekend: Canadian Brass: Home.

Again, this is probably not pertinent to what you are looking for, but I can tell you that if there was ever a project that suffered from scope creep, it was the above site. The teams I've worked in have never exceeded four people (as far as I recall), but I would be willing to bet that whether you are talking about a website, a mobile app, an enterprise app, a game, or anything else the same traps can apply.

It has been my experience that clients especially want to start fussing over the UI and how things should look before really getting a handle on the fundamentals. Again, if this doesn't apply to you, great, but you don't have to go much further than sites like Freelancer/Guru or the like to see a lot of hair brained business plans out there.

I apologize if you are feeling defensive because when I said that I'd be surprised if this didn't apply to you I meant something personal in relation to what I know of you. Other than the fact that you like to go at it with Spheric Harlot, I don't really know much about you. I meant what I said just in a general way, taking averages and what is most common in my experiences into account. Again, I don't doubt the soundness of your business model behind your app.

[AvisNocturna]

GUI mockups are important. More important is separating your GUI code from the "Core" code.

In my cocoa projects, the core is totally separated from the GUI. I have a core framework for each project that contains all the core classes and an app that contains all GUI elements like XIBs, table views, sheets etc. But the app is a very thin layer atop of the core framework. For example, my newest app Logoist (see thread "Looking for beta testers") has a Core which contains all rendering, the object model, filters and so on. The app contains the app window, layer list, sheets etc.

This way It is much easier to refactor your GUI code when you came to the conclusion that your current GUI concept is not working out. A nice side effect of this is that it produces MUCH cleaner code since you do not mix the GUI and core code. You push yourself to define clean programming interfaces this way.

[Wiskedjak]

Originally Posted by freudling 

Finally, the Chief Engineer thinks that people working anymore than 40 hours a week are wasting time because their productivity will suffer. However, I work 12 hours per day. We're a tech start up.

Any comments, suggestions, or advice?

There is plenty of research stating that productivity suffers in sustained periods of work over 40 hours/week. Spikes of long hours are fine, but sustained hurts. The average person will get more work done in a 40 hour week than in a 50 hour week. There are some who suggest that a 35 hour week is even more productive than a 40 hour week.

[freudling]

Originally Posted by Wiskedjak 

There is plenty of research stating that productivity suffers in sustained periods of work over 40 hours/week. Spikes of long hours are fine, but sustained hurts. The average person will get more work done in a 40 hour week than in a 50 hour week. There are some who suggest that a 35 hour week is even more productive than a 40 hour week.

While I agree that sustained overtime may lead to burnout, these articles all seem to be written by middle age parents. Sometimes you just have to work overtime to get the job done. This whole "don't work more than 40 hours per week" movement started recently when a post on LinkedIn went viral. The studies are decades and 100 years old.

There are far too many variables to consider to generalize that working more than 40 hours per week is "bad".

What industry? How old is the person? Do they have a family? Are they naturally energetic? Is it a tech start up? On and on.

My engineers put in 8 hours a day, then go home and hang out on their computer programming personal stuff and surfing the Web. The sprints aren't getting done completely. I want them to work more to get the job done.

One of programmers came in so tired for a few days and it wasn't because of the job. He stayed up late doing his taxes, even though he has every single weekend off.

[Wiskedjak]

Originally Posted by freudling 

While I agree that sustained overtime may lead to burnout, these articles all seem to be written by middle age parents. Sometimes you just have to work overtime to get the job done. This whole "don't work more than 40 hours per week" movement started recently when a post on LinkedIn went viral. The studies are decades and 100 years old.

The whole "don't work more than 40 hours per week" dates back to the industrial revolution. Even Henry Ford found 8 hour days to result in a more efficient assembly line. True, spikes of overtime can be effective, but sustained overtime will result in burnout or losing your best people to greener pastures.

Originally Posted by freudling 

What industry? How old is the person? Do they have a family? Are they naturally energetic?

Also agreed. But, I don't think you want tired devs coding. You'll just end up with sloppy code that'll end up costing you more in QA and bug-fixing.

Originally Posted by freudling 

Is it a tech start up?

This is one of the worst excuses: "we're a tech startup so we run long hours". Meh, I know of several tech startups that run 40 hour weeks, and do so in order to be able to attract top talent.

Originally Posted by freudling 

My engineers put in 8 hours a day, then go home and hang out on their computer programming personal stuff and surfing the Web. The sprints aren't getting done completely. I want them to work more to get the job done.

You mean your devs actually want to have a life outside of work??? OMG! How incredibly selfish.
If the sprints aren't getting done, you have one of three problems:
- unqualified devs for the work expected of them (management/hr problem)
- poor project management (management problem)
- unrealistic expectations for how much work can be done by one person in a 40 hour week (management problem)

I suppose you also expect to not have to pay them for their overtime?

Originally Posted by freudling 

One of programmers came in so tired for a few days and it wasn't because of the job. He stayed up late doing his taxes, even though he has every single weekend off.

That's a management problem. You can't blame your staff for wanting to have a life outside of work, but you can penalize them if that life interferes with their time on your dime. If he's performing poorly, let him go.

[freudling]

Originally Posted by Wiskedjak 

The whole "don't work more than 40 hours per week" dates back to the industrial revolution. Even Henry Ford found 8 hour days to result in a more efficient assembly line. True, spikes of overtime can be effective, but sustained overtime will result in burnout or losing your best people to greener pastures...

Bottom line: different strokes for different folks.

I work at least 60 hours per week and like it. I'm productive.

I have half the people here working at a pretty good pace, even coming in on the weekends on their own. They like the work. The other half are ok, but don't produce as must as the other half.

I spoke to someone last night who manages and they say that the younger people in their 20s aren't producing as quickly. I asked if it was a lack of experience and she said not really... it's just a different mindset.

Managing is about results. And to get results you have to meet deadlines. And to meet deadlines you have to work to achieve milestones to meet those deadlines. More times than not in my experience working extra time is required.

And if you want to talk about keeping top talent by limiting the work week to 40 hours per week... I don't think you're living in reality.

Apple, for instance, has regularly ran engineers and managers into the ground. And not just under Steve Jobs, but under Sculley too.

The making of the iPhone, for instance, and how management was getting frustrated... engineers were quitting and coming back 2 weeks later refreshed.

The Untold Story: How the iPhone Blew Up the Wireless Industry

Or under Sculley and how one engineer committed suicide on the Newton project, and Steve Capps, the Lead, coded for some 20 hours per day for many months in his basement so he wouldn't be disturbed. He had one of the first T3 lines in the US to a home from what I read.

I don't advocate this extreme, but working extra here and there, especially at a start up... especially when you're being paid well and are given equity... is what I expect. I expect you to love this and marry this for 6 months. If not, I'll find someone else.

[P]

The original Macintosh project was like that, but just about everyone deeply involved in it was burnt out and left the company afterwards. You CAN work like that, if it is for a time-limited project and you get to take a break after, but you can't do it year in and year out.

[freudling]

Originally Posted by P 

The original Macintosh project was like that, but just about everyone deeply involved in it was burnt out and left the company afterwards. You CAN work like that, if it is for a time-limited project and you get to take a break after, but you can't do it year in and year out.

I'm not asking to do it year after year. It's a get to market thing that's 6 months. If you come in and act indifferent with no sense of urgency... what I'm saying is, you're doing it wrong and I'll find someone else who understands just what it takes to 1. Get to market 2. Compete with people in the world.

Punching a clock, coming late and leaving early... that has no place here. I'm not going to an extreme but clock punching isn't going to get us there.

[Twilio]

i think you have to hire some more designers or if you want to talk about keeping top talent by limiting the work week to 40 hours per week... I don't think you're living in reality.

[BLAZE_MkIV]

Originally Posted by P 

The original Macintosh project was like that, but just about everyone deeply involved in it was burnt out and left the company afterwards. You CAN work like that, if it is for a time-limited project and you get to take a break after, but you can't do it year in and year out.

And you need to give them enough stock options that they're millionaires if it works.