No matter what framework or method your management thinks they are applying, learn to work this way: Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day. Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible. Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next. This is the development team’s best hope for a reasonable life. By keeping the software always ready… Read more →
EppsNet Archive: Deadlines
Teaching Computer Science: The Last Minute
“Reminder that your projects are due tomorrow so don’t wait till the last minute. Oh wait, this is the last minute.” Deadlines can be fun when they apply to other people . . . Read more →
Hard Deadlines
Does saying “This task has to be done by Friday” increase the chances that the task will be done by Friday? No, but it increases the chance that it won’t be done before Friday. Better question: Why isn’t it done now? Thus spoke The Programmer. Read more →
How to Get on My Bad Side
Walk into my office the day after your project is approved and say, “When are we getting a team together for my project? Because I don’t plan to miss my deadline.” Slap the back of one hand into the palm of the other for emphasis. Read more →