131–140 of 208 posts
If you're building a Mars lander, time is everything because if you miss your launch window, you need to wait 18 months for the next one. Most of us are doing something else.
Alternate view point - driving projects to a specific deadline allows the other departments in the company to coordinate marketing, packaging, and selling the product. These people don't sit on their hands patiently waiting for engineers to finish building, their work can take many months just as the development does, and sometimes also involves making tradeoffs to deliver on time. No company wants to wait another ye…
Yeah, this is an unfortunate truth that Agile has to confront; there may be hard coordination deadlines. Or, in startups, a financial "runway". On the other hand, setting a deadline can't force something to be possible, it can only force people to work harder and more painfully towards it. I'm sure the Amazon drone delivery failure had a date target, for example. And there have been plenty of failed "big bang" IT mig…
It's so you can (hopefully) have an educated understanding of setting that deadline, and then how you're progressing towards it. It's so if you're not on track to deliver, you can make more educated decisions about cutting scope, or adding resources (yes yes yes, i know).
Earlier quoted context omitted.
You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high…
Yes, I've been writing it alone, but my "alone" work is at a different level, from what many folks do. Approaching every bit of work I do as "ship," is one of my oddities. I have as much fun, shipping , as I do writing. I consider everything I do, "engineering." Been doing that, all my adult life. Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a numb…
There is nothing wrong with working to dead lines estimating and planing development and releasing software thats good enough not perfect. The problem is when people start trying to change the plan half way through execution, non tech people will constantly try to do this because they are clueless its the project leads job to tell them no. When your manager asks you "if anything can be done to pull those dates in." y…
Earlier quoted context omitted.
You worked on that app yourself alone, right? If so, I believe your app belongs to a different plane of existence. Programming (one programmer working alone without too much money/time pressure imposed by others) is quiet different from software engineering (multiple programmers, stakeholders, designers, etc., with time and money constraints). Everyone loves programming (and so doing programming usually leads to high…
I would say a lot of this confusion comes from the word engineer. Building software is not like building a bridge. You can't design it first and then go and build it. So I would say engineer is a poor term, but also the only one we've got for now.
You can't design it in full in one go, but you can design it and then incrementally update said design. Sadly many (companies) do not. But you can define the problem(s), the scope, the scale, and then design a solution appropriately to meet those needs (for a defined period of time). That's what distinguishes software engineering from hacking. They both have their place. Many companies claim to do the former but are mostly doing the latter. Software is still early in its life and as various kinds of system designs stabilize, so will the formalizations around what it means to be a software developer. Reading a book like Designing Data Intensive Application's you can't help but see those formalized topics budding.
Chapter 11. Plan to Throw One Away Chemical engineers learned long ago that a process that works in the laboratory cannot be implemented in a factory in only one step. An intermediate step called the pilot plant is necessary to give experience in scaling quantities up and in operating in nonprotective environments. For example, a laboratory process for desalting water will be tested in a pilot plant of 10,000 gallon/…
i must say, the mythical man-month should be a must-read* for any technical managers or execs in a tech org (hmmm throw devs in that list too)
*and maybe re-read every year to keep it fresh in mind
Earlier quoted context omitted.
Yes, I've been writing it alone, but my "alone" work is at a different level, from what many folks do. Approaching every bit of work I do as "ship," is one of my oddities. I have as much fun, shipping , as I do writing. I consider everything I do, "engineering." Been doing that, all my adult life. Feel free to look at the stuff I do (I link to it in my HN profile). The app I'm working on isn't there (yet), but a numb…
I wonder if the nuance being identified by the other commenters might be the tragedy of the commons that can play out in collaborative settings. I'm right there with you, btw. Mine is also a non-sexy, non-commercial app and I'm happily a one man band. But a younger me, a junior member of a team, under pressure without close supervision would probably commit a certain amount of half baked spaghetti and be part of the…
It's not exactly a "one-man show," but I'm the chief architect, and the only one developing one of the three servers the app uses (I was also the original architect for another server, that is now being run by a different open-source team), I am also the only one developing the native iOS application. I may be writing some adjunct apps, once the main one has been released (like Watch, Mac and TV apps).
But we're a team. It's a 501(c)(3), with a mission to Serve a specific demographic. We have the advantage of being intimately familiar with the demographic. So far, we haven't had to shell out much. If they decide to write an Android version, then it may take some extra dosh. The good news is, the app is in "constant ship" state, so asking for funding is fairly straightforward. We just need to loop the person into the TestFlight group, and Bjørn Stronginthearm is your uncle.
The problem that the article doesn't address is that users don't actually seem to mind using terrible software so long as it solves the problem they face better than not using it. I could list literally hundreds of half-assed, broken, bloated applications that I've encountered in the past 25 years that have done very well simply because they kind of solve a problem a bit for the user. Pushing out something completely…
>The problem that the article doesn't address Another. Industries that are oriented towards tradeshow or holiday launches. It ain't like they're going to move NAB or Christmas just for you. Inevitable feature pruning occurs. Having said that, I wonder how many of the great fortunes have been built on horrid, half-finished websites and associated software that were all about being first out of the gate and heavy marke…
Earlier quoted context omitted.
The first mover advantage is huge. Once users have already chosen to use your software it will take something substantially better over an extended period of time for most to move over to a competitor that has solved it better. The risk of that happening when you are already making money and solving the problem and have most of the market is small. If you keep irritating your customers and they have a better alternat…
The first mover advantage is an illusion. Google didn’t invent search or online Email. Microsoft didn’t pioneer personal computing, spreadsheets, or word processing. Facebook wasn’t the first social network. Apple made most of it’s money from markets it entered late iPod, iPhone, and then iPad where the Newton failed. Intel wasn’t the first to build a microprocessor. IBM didn’t invent the computer.
Despite that, hotmail still exists.
While first mover doesn't guarantee success, it's certainly an illusion.
There is nothing wrong with working to dead lines estimating and planing development and releasing software thats good enough not perfect. The problem is when people start trying to change the plan half way through execution, non tech people will constantly try to do this because they are clueless its the project leads job to tell them no. When your manager asks you "if anything can be done to pull those dates in." y…
The challenge is that there are no hard rules and it's highly dependent on the context. That requires mutual understanding and trust between the business and development.